Czy dodanie przedrostka „tbl” do nazw tabel naprawdę stanowi problem?

92

Oglądam niektóre filmy Brenta Ozara ( na przykład ten ) i sugeruje, aby nie poprzedzać tabel za pomocą ‘tbl’lub ‘TBL’.

W Internecie znalazłem kilka blogów, które mówią, że nic nie dodaje do dokumentacji, a także, że „czytanie trwa dłużej”.

Pytania i uwagi

  • Czy to naprawdę problem? Ponieważ poprzedzam tabele przedrostkiem „tbl” od mojej pierwszej pracy dba (starszy DBA powiedział mi, żebym robił to dla organizacji).
  • Czy to coś, czego muszę się pozbyć? Zrobiłem kilka testów, kopiując naprawdę duży stół i nadając mu prefiks „tbl”, jednocześnie utrzymując drugi bez niego, i nie zauważyłem żadnego problemu z wydajnością.
Racer SQL
źródło
66
Przeciwdziałanie: czy poprzedzasz wszystkie swoje klasy językiem programowania (Java, C ++, Scala, ....) Class?
a_horse_w_no_name
78
Gdy „czytają go dłużej”, nie mają na myśli problemów z wydajnością. Ludzie czytają kod dłużej. Co jest łatwiejsze do odczytania? To zdanie: Wrdthis wrdis wrda wrdsimple wrdsentence. czy to jedno: This is a simple sentence.?
ypercubeᵀᴹ
3
Może to być powiązane: stackoverflow.com/questions/111933/…
Walfrat
42
Oto praktyczny argument przeciwko temu. Często przydaje się wpisanie pierwszej litery nazwy tabeli, aby zeskoczyć na listę. Gdy wszystkie tabele zaczynają się od „t”, to już nie działa. Podobnie, nie pomoże ci to w IntelliSense.
shawnt00,
30
Nie jestem DBA, jestem programistą. Ale proszę nie rób tego. Spowalniasz mnie i sprawiasz, że mój kod jest trudniejszy do odczytania i utrzymania. I po co? Nie widzę żadnej korzyści.
Dawood ibn Kareem,

Odpowiedzi:

217

Kiedyś miałem stolik, który był błyszczący i piękny. Przechowywał wszystkie transakcje finansowe dla organizacji. A potem zaczęliśmy ładować do niego dane.

W bieżącym miesiącu mogą one określać i przekształcać wartości tak często, jak chcą. W ostatnich 10 dniach miesiąca przekształcają liczby -> uruchamiają przetwarzanie ETL -> przeglądają raporty kilka razy dziennie. Po zakończeniu miesiąca książki są zapieczętowane i nie można modyfikować wartości.

To niesamowite, ile danych finansowych generuje firma świadcząca usługi finansowe ... Z naszym zestawem danych testowych nie zdawaliśmy sobie sprawy, że ilość danych sprawi, że ich procedury na koniec miesiąca staną się niemożliwe do utrzymania. Usunięcie „danych z bieżącego miesiąca” zajęło coraz więcej czasu, zanim zastąpiono je nowym przebiegiem próbnym.

Musieliśmy zrobić coś, aby przyspieszyć przetwarzanie bez łamania nieskatalogowanej listy „kto wie, co”, wszystko zależy od tabeli MonthlyAllocation. Postanowiłem zagrać w magika i wyciągnąć spod nich obrus. Poszedłem do starej szkoły i korzystałem z widoku podzielonego na partycje . Dane miały już flagę IsComplete, więc utworzyłem dwie tabele - każda z przeciwnymi ograniczeniami sprawdzania: MonthlyAllocationComplete, MonthlyAllocationInComplete

Następnie utworzyłem widok podzielony na partycje o tej samej nazwie co oryginalna tabela: MonthlyAllocation. Żaden proces nie był mądrzejszy w kwestii fizycznej zmiany, której dokonaliśmy w bazie danych. Nie zgłoszono żadnych raportów, żaden z analityków z bezpośrednim dostępem nie zgłosił żadnych problemów z tą „tabelą” przed ani po niej.

Fajna historia, stary, ale gdzie idziesz?

Co jeśli mieliby tam konwencję nazewnictwa, tbl_MonthlyAllocation? Co teraz? Czy spędzamy wiele roboczogodzin, przeglądając każdy ETL, każdy raport, każdy arkusz kalkulacyjny ad-hoc w organizacji i aktualizując je, aby używały vw_MonthlyAllocation? A potem oczywiście wszystkie te zmiany przechodzą przez Tablicę Zmian i zawsze jest to szybki i bezbolesny proces.

Twój szef może zapytać: jaka jest nagroda dla firmy za całą tę pracę?

Inną opcją jest pozostawienie tego widoku jako tbl_ i nie poświęcanie całego czasu na testowanie, aktualizowanie i wdrażanie kodu. Staje się to zabawną anegdotą, którą objaśniasz wszystkim nowym pracownikom, a także osobom o krótkiej uwadze, które muszą pracować z bazą danych, wyjaśniając, dlaczego nie zgadzasz się z nazewnictwem obiektów

Lub nie podwójnie kodujesz obiektów z redundantnymi metadanymi. Baza danych szczęśliwie powie ci, co to jest tabela, co to jest widok, co to jest funkcja o wartości tabeli itp.

Konwencje nazewnictwa są dobre, po prostu nie maluj się nimi w kącie.

billinkc
źródło
132

Brent tutaj (facet, którego dotyczy pytanie).

Powód, dla którego mówię wam, abyście nie dodawali tbl z przodu nazwisk twoich tabel, to ten sam powód, dla którego powiedziałbym, aby nie dodawać dziecka z przodu imienia twojego dziecka. Nie nazywacie ich childJohn i childJane. Nie tylko nie wnosi żadnej wartości, ale może nie być dzieckiem w późniejszym życiu - a twoje przedmioty mogą później stać się widokami.

Brent Ozar
źródło
10
Jeśli piszesz instrukcję insert, mam poważną nadzieję, że już wiesz, czy to, co wstawiasz, to tabela czy widok ...
Joe
@Joe: „Mam nadzieję, że wiesz, czy wstawiasz tabelę czy widok” - istnieją okoliczności, w których możesz wstawiać widok i twój kod nie powinien się tym przejmować (niektóre silniki obsługują obsługę danych w wystarczająco prostych widokach, a instead ofwyzwalacze mogą umożliwić bardziej skomplikowane przykłady). Chociaż nadal oznacza to, że nie potrzebuję / nie chcę prefiksu nazwy.
David Spillett
119

To bardzo subiektywny argument, ale oto moje zdanie: przedrostek tbl jest bezużyteczny.

Ile scenariuszy patrzysz na kod i nie wiesz, czy coś jest stołem czy czymś innym?

Jaką wartość dodaje tbl oprócz tego, że patrząc na listę tabel w Eksploratorze obiektów, musisz wykonać więcej pracy, aby znaleźć tę, której szukasz?

Niektórzy twierdzą, że chcą, aby kod był wyraźny, gdy mają do czynienia ze stołem lub widokiem. Dlaczego? A jeśli jest to ważne, dlaczego nie tylko nazwać widoki w specjalny sposób? W większości przypadków działają one jak tabele, więc nie widzę żadnej wartości w rozróżnianiu.

Aaron Bertrand
źródło
11
Na przykład w PostgreSQL widok jest w rzeczywistości tabelą: postgresql.org/docs/9.6/static/rules-views.html - więc różnica jest jeszcze mniej ważna.
dezso,
42

To okropna praktyka.

tbl
tbl_
Table_
t_

... widziałem ich wszystkich w produkcji.

Jeden z produktów, nad którym obecnie pracuję, ma połowę nazwanych tabel tbl_whatever, a druga połowa „normalnie” - najwyraźniej mają programistów, którzy pracują według różnych standardów. Kolejnym z ich złych nawyków jest poprzedzanie nazw kolumn kluczami obcymi fk, po których następuje nazwa tabeli, fka następnie nazwa kolumny, co daje tak okropne nazwy kolumn jak fktbl_AlarmsfkAlarmsID. Ta konwencja nazewnictwa jest tylko logicznym rozszerzeniem całej tbl_%mantry i widać, jak śmiesznie się to robi!

Prawie zapomniałem o innej bazie danych, która sprawia, że ​​płaczę codziennie. Typy danych poprzedzające nazwy kolumn ... dtPaymentDate, ponieważ nazwa naprawdę potrzebowała dtprzedrostka? `

Philᵀᴹ
źródło
22
Przynajmniej nie pracujesz z bazą danych z rozróżnianiem wielkości liter, więc tbl_Foo i Tbl_Foo nie są różnymi jednostkami ...
billinkc
23

NIE PRZEGLĄDAJ PRZYGOTOWANIA DO PRZYSTĄPIENIA DO INNYCH OSÓB. proYou auxOdpowiedni zawsze werAtUjNePrefixes prepW proYour twojNastępne nazwy. proI auxHave ZALECAJĄ ROZPOCZĘCIE ROZPOCZĘCIA PROPOZYCJI NAPISU NORMALNEGO.

ZOBACZ PORADY W JAKI SPOSÓB DOSTĘPNE WERSJE PROJEKTOWE? NouPeople AuxCan verUnderstand proTwoJej nowSzej Regulacji!

ErikE
źródło
Daj nam kontynuować tę dyskusję w czacie .
sampathsris
21

Używanie takiego przedrostka jest znane jako notacja węgierska . Założenie jest proste: możesz określić, co to jest, na podstawie jego nazwy. Jest to szczególnie powszechne w językach programowania, szczególnie gdy programiści piszą funkcje monolityczne obejmujące kilkadziesiąt stron, albo z powodu braku umiejętności, albo z braku funkcji językowych. To mnemoniczna pomoc, która pomaga programistom w utrzymywaniu prostych typów danych.

Ogólnie rzecz biorąc, ten styl nazewnictwa jest prawdopodobnie używany w naprawdę starym kodzie lub przez programistów, którzy albo dopiero się uczą (i nauczyli się tego nawyku), albo robią to tak długo, jak pamiętają. Z mojego doświadczenia wynika, że ​​stosunkowo rzadko notuje się spontaniczne notowanie węgierskie wśród niedoświadczonych programistów, jeśli nie zostaną im przedstawione przez kurs programowania lub samouczek; są one bardziej prawdopodobne, aby używać nazw zmiennych jak I lub X lub acct .

Oprócz malowania się w kącie, jest to naprawdę tylko wypełniacz. Składnia SQL jest na tyle precyzyjna, że ​​deweloper powinien zawsze wiedzieć, czy mówi o polu, rekordzie lub zestawie danych (którym może być tabela, widok itp.). Chociaż może stanowić świetną pomoc dydaktyczną, ta składnia zwykle nie powinna istnieć w produkcyjnych bazach danych. Może to zaszkodzić czytelności i utrudnić znalezienie poszukiwanego stołu, zwłaszcza jeśli pojawi się kilka alternatywnych motywów nazewnictwa, takich jak tbl vs. table vs. tab itp.

Baza danych tak naprawdę nie dba o to , co nazywamy tabelami, polami itp. Są to tylko bajty danych ułożone w określonej kolejności przez ich ludzkich operatorów lub skrypty. Jednak ludzie, którzy muszą przechowywać te dane, docenią znaczące nazwy, takie jak „użytkownik”, „zamówienie” i „konto”. Jest to również bardziej praktyczne, jeśli używasz zapytań SQL, takich jak „pokaż tabelę jak„% ”. Używanie prefiksów i sufiksów może niepotrzebnie komplikować w inny sposób banalną konserwację.

phyrfox
źródło
14
Podobnie jak wielu, którzy nadużywają notacji węgierskiej, twoja odpowiedź przeciwko niej całkowicie pomija różnicę między Apps Hungarian a Systems Hungarian.
Ben Voigt,
8
@BenVoigt, bardzo prawdziwe. Ale zapomniałeś obowiązkowego linku .
Wildcard,
12

Przeczytałem kilka takich postów na blogu, takich jak ten lub ten (jest ich sporo), po odziedziczeniu mojej pierwszej instancji programu SQL Server i zauważyłem wiele obiektów, których prefiksy chciałem zacząć opracowywać nowe z mniej szczegółowym podejściem i pojedynczą konwencją nazewnictwa ( o wiele łatwiej mi [ i ewentualnie innym programistom ] pracować nad Object Relational Mapping).

Jednym z najczęściej używanych prefiksów było Tblalbo tbl, ale wtedy miałem TBLi tbl_nawet*TableName*_Tbl

wprowadź opis zdjęcia tutaj

Próbowanie zapytania i pracy z Visual Studio to po prostu piekło, nie miałbym znaczenia, że ​​mam cały zestaw prefiksów tabeli, tblale proszę, zachowaj to w ten sposób przynajmniej dla całej bazy danych.

Tak więc ostatecznie powiedziałbym, że jest to kwestia osobistych preferencji, ale ma również wiele wspólnego ze spójnością, a jeśli pójdziesz tą drogą, wiele osób będzie zadowolonych, przynajmniej utrzymasz to samo podczas rozwoju.

... Z drugiej strony chciałem tylko powiedzieć, że jeśli podejmiesz inne podejście i wybierzesz nieprefiksową tablicę z nazwami pojedynczymi, w przyszłości sprawisz, że deweloper będzie szczęśliwy, a co jest ważniejsze niż szczęście?

Nelz
źródło
11

Tak, dodanie przedrostka oznaczającego typ obiektu stanowi problem i jest niepotrzebne . Dlatego,

  1. Czasami przedmioty zaczynają życie jako coś, ale ostatecznie stają się czymś innym . (np tabela tblXxxzostała podzielona na tblXxxYi tblXxxZz jakiegoś powodu i zastąpione z myślą, że łączy dwie nowe tabele. Teraz masz widok nazwie tblXxx).
  2. Gdy piszesz tblw edytorze, jego funkcja autouzupełniania zawiesza się na 45 sekund, a następnie wyświetla listę 4000 wpisów.

Ale...

Będę grał w adwokata diabła i powiem coś, czego inni odradzali. W niektórych rzadkich przypadkach przydatny może być przyrostek / przedrostek, a oto przykład organizacji, dla której pracuję.

Mamy oparty na jednostkach system ERP, w którym logika biznesowa jest napisana w Oracle PL / SQL. Ma prawie dwie dekady, ale jest bardzo stabilnym systemem (nie jest to starszy system. Cały czas go rozwijamy).

System jest oparty na jednostkach, a każda jednostka wiąże tabelę, wiele widoków, wiele pakietów PL / SQL i wiele innych obiektów bazy danych.

Teraz chcemy, aby obiekty należące do tego samego bytu miały tę samą nazwę, ale aby można było je było odróżnić od celu i rodzaju. Tak więc, jeśli mamy dwa podmioty, które są nazwane CustomerOrderi CustomerInvoice, będziemy mieli następujące obiekty:

  1. Tabele do przechowywania danych [ TABsufiks]:
    • CUSTOMER_ORDER_TAB
    • CUSTOMER_INVOICE_TAB.
  2. Widoki używane przez klientów [Bez sufiksu]:
    • CUSTOMER_ORDER
    • CUSTOMER_INVOICE.
  3. Interfejs do podstawowych operacji; (Pakiety PL / SQL) [ APIsufiks]:
    • CUSTOMER_ORDER_API
    • CUSTOMER_INVOICE_API.
  4. Generatory raportów; (Pakiety PL / SQL) [ RPIsufiks]:
    • CUSTOMER_ORDER_RPI
    • CUSTOMER_INVOICE_RPI.
  5. Indeksy dla kluczy podstawowych [ PKsufiks]:
    • CUSTOMER_ORDER_PK
    • CUSTOMER_INVOICE_PK.
  6. Indeksy wtórne [ IXsufiks]:
    • CUSTOMER_ORDER_XXX_IX
    • CUSTOMER_INVOICE_XXX_IX(gdzie XXXopisuje użycie indeksu).
  7. ... i tak dalej.

Jest to rzeczywiście forma aplikacji węgierskiej (zwróć uwagę, że ten sam typ obiektów może mieć różne sufiksy w zależności od celu). Ale z przyrostkiem zamiast przedrostka. Nie mogę powiedzieć wystarczająco dużo, jak ten system jest tak łatwy do odczytania. IntelliSense faktycznie działa, ponieważ zamiast pisać TBLi uzyskiwać 4000 wyników, mogę pisać Customeri pobierać wszystkie obiekty należące do nazwanych podmiotów Customer*.

Więc tutaj pokazałem, jak metadane mogą być przydatne. Celem jest posiadanie pokrewnego zestawu obiektów bazy danych identyfikowanych za pomocą jednej nazwy, a jednocześnie różnicowanie ich na podstawie ich celu .

Powiedziawszy to, jeśli nie masz tego rodzaju systemu, nie ma potrzeby ani prefiksu, ani sufiksu typu obiektu .

Zauważ, że nie zostały wykorzystane przyrostków jak _table, _packagelub _view(czyli typu obiektu). Na przykład zarówno (3), jak i (4) są pakietami PL / SQL, ale używają innego sufiksu. To samo dotyczy (5) i (6), z których oba są indeksami. Zatem przyrostek jest oparty na celu, a nie na typie .

sampathsris
źródło
3
Wdrażam ten produkt ERP, a konwencja nazewnictwa jest bardzo przydatna do wzmocnienia wzorca „Skonsultuj widok, zaktualizuj za pomocą interfejsu API” i unikaj pokusy, aby aktualizować tabelę bezpośrednio, bez uważnego rozważania logiki biznesowej.
grahamj42,
10

tl; dr To (bardzo prawdopodobne) dodaje zbędne informacje, prowadząc do narzutu poznawczego i dlatego powinno zostać usunięte.

Kontekst jest cudowną rzeczą, szczególnie w systemach komputerowych. Poza kontekstem nie można stwierdzić, czy coś, co się nazywa, usersjest tabelą, widokiem, procedurą składowaną czy czymś zupełnie innym. Starsze (lub po prostu źle napisane) systemy i języki często utrudniają wypracowanie kontekstu podczas czytania kodu. Na przykład w Bash nie można powiedzieć, co się function usersdzieje bez przynajmniej przeczytania zawartości funkcji. W Javie Map<Uid,UserDetails> users()jest dość przejrzysty i można łatwo zagłębić się w szczegóły.

Biorąc ten argument do tabel SQL, kiedy konsumenci powinni userswiedzieć, czy jest to tabela, czy widok? Innymi słowy, czy tblprzedrostek powie jednemu z konsumentów coś, czego nie znają i co powinni wiedzieć?Mamy nadzieję, że zdecydowana większość konsumentów będzie pisać przeciwko nim zapytania DML i DQL. Dla nich powinno to być kolejne źródło danych, a to, czy jest to widok, czy tabela, powinno być tak samo istotne, jak to, czy jest podzielone na partycje, przechowywane na HDD lub SSD, czy jakikolwiek inny szczegół techniczny. DBA oczywiście musi znać te szczegóły, aby uruchamiać niektóre rzadkie zapytania DDL / DCL, ale zanieczyszczanie przestrzeni nazw ze względu na mniejszość, która naprawdę wie, jak poruszać się po schemacie i uzyskać wszystkie szczegóły techniczne, wydaje się nieskuteczne.

10b0
źródło
9

Jedną z cech systemu zarządzania relacyjnymi bazami danych jest to, że oddziela ono logiczną prezentację informacji od klientów od pamięci fizycznej. Pierwsza z nich to kolumny w zestawie wierszy. Ten ostatni jest w postaci plików na woluminie pamięci. Zadaniem DBMS jest mapowanie jednego do drugiego. Dotyczy to tylko DBA lub sysadmin, który sprzęt obsługuje potrzeby informacyjne. Konsument nie musi, a nawet nie powinien, być świadomy tych obaw.

Klient nie powinien również przejmować się budową zestawu wierszy. Tabela bazowa, widok lub funkcja są pod tym względem identyczne. Każdy z nich po prostu tworzy zestaw wierszy i kolumn, które klient zużywa. Nawet prosty skalar można uznać za tabelę z jednym wierszem i kolumną. Model wiersza / kolumny jest umową między klientem a serwerem.

Dzięki prefiksowi nazw artefaktów rodzajem ich implementacji ten podział problemów zostaje przerwany. Klient jest teraz świadomy wewnętrznych elementów serwera i zależy od nich. Zmiana w kodowaniu serwera może wymagać ponownej pracy klienta.

Michael Green
źródło
8

Istnieje wiele odpowiedzi, z którymi się zgadzam, które mówią, że nie jest to bardzo cenna konwencja nazewnictwa. Dla tych ludzi, których inne odpowiedzi nie przekonują, postaram się wykazać, co mówi wiele innych odpowiedzi.


SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

W powyższym stwierdzeniu wybieram trzy kolumny z czegoś o nazwie dbo.foo. Jedną z głównych skarg prefiksów jest to, że nie wiedzą, czy dbo.foojest to tabela, czy widok. Oczywiście jest to jedna z zalet poglądu jako abstrakcji, ale dygresuję. Mówią, że powinniśmy poprzedzić taki obiekt dbo.tblFoo. Teraz widzą, że obiekt jest tabelą (prawdopodobnie) w powyższym zapytaniu. Jeśli jednak napiszemy funkcjonalny odpowiednik tego celu, wyglądałoby to następująco.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

Podejrzewam, że komentarz wydaje się mniej niż przydatny, chociaż o to skutecznie argumentują prefiksy. Aby podkreślić bezużyteczny szum, który wprowadza ten komentarz do metadanych, rozważ bardziej skomplikowane zapytanie.

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

Czy dodatkowe komentarze sprawiają, że zapytanie jest łatwiejsze do uzasadnienia, czy po prostu powodują dodatkowy hałas? Moim zdaniem po prostu dodają dodatkowy hałas i dodają zerową wartość. Właśnie to starają się powiedzieć prefiksy. Ponadto używanie prefiksów jest w rzeczywistości gorsze niż te komentarze, ponieważ koszt aktualizacji komentarza jest znacznie niższy niż aktualizacja nazwy tabeli z prefiksem, jeśli model danych wymaga dostosowania. Ponieważ prefiksy te mają swój koszt i nie dostarczają cennych informacji, należy ich unikać.

Inną zaletą przedrostków, które cytują niektóre osoby, jest to, że może nadawać pewne grupowanie lub porządkowanie w środowisku programistycznym. Ponieważ spędzamy dużo czasu na edytowaniu kodu, dla niektórych może to być uwodzicielski argument. Jednak z mojego doświadczenia wynika, że ​​nowoczesne środowiska programistyczne zapewniają równoważne lub lepsze opcje, które nie zaśmiecają kodu niepotrzebnymi metadanymi i ograniczają elastyczność.

Erik
źródło
7

Zostało to omówione wiele razy, ale prawdopodobnie najbardziej znany Joe Celko , amerykański ekspert SQL i relacyjnych baz danych. Osobiście byłem na przyjmowaniu jednego z jego rantów online (czułem się zaszczycony), a on mówi o tych prefiksach jako „gadanie”, a dokładniej określane jako „ skeuomorfizm ”.

Ogólna idea polega na tym, że te przedrostki są praktyką kodowania sprzed wielu lat (prawdopodobnie z powodu ograniczeń nazewnictwa, takich jak 8-bajtowy limit nazw obiektów), przekazywanych pokoleniom programistów bez pozornie przydatnego powodu, poza tym, że jest to po prostu „sposób zrobione".

Firmy, blogerzy i programiści przekazują informacje z własnym stylem kodowania, a niektóre style mogą być nieco bardziej „Frankenstein” niż inne. Firma może mieć „styl domu”, a programista jest zmuszony nauczyć się tej praktyki.

Z biegiem czasu rzeczy się utrzymują, nawet jeśli powód ich pierwotnego użycia jest już nieaktualny. „Tibbling” jest jednym z najbardziej znanych przykładów tego zarządzania relacyjnymi bazami danych.

Podsumowując: nie dodaje żadnej wartości, dodaje dokładnie 4 bajty miejsca do przechowywania w każdej nazwie tabeli bez żadnego innego powodu niż to, że tam jest. Nie oferuje nic nowoczesnym systemom SQL Server, ale jeśli dzięki temu poczujesz się lepiej, skorzystaj z niego.

John Bell
źródło
8
Głosowałem za odpowiedzią z powodu linijki: „ale jeśli dzięki niej poczujesz się lepiej, to idź dalej i skorzystaj z niej”. To okropny powód do korzystania z konwencji.
jpmc26,
@ jpmc26 Zgadzam się, jednak jest to jednak powód i może z niego korzystać.
John Bell
6
@JohnBell, ale możesz go nie polecić ...
dan1111,
@ dan1111 Rzeczywiście jestem i myślę, że z ogólnego tonu mojej odpowiedzi każdy, kto ma jakieś logiczne rozumowanie - które, mam nadzieję, powinien posługiwać się dowolnym językiem programowania, byłby w stanie wywnioskować, że nie zaleca się używania „tbl_” lub „ _tbl ”.
John Bell
5

Sugeruję, żebyś natychmiast przestał to robić. Jeśli to sprawia, że ​​czujesz się niekomfortowo, dodaj „_tbl” na końcu nazw swoich tabel. Oczywiście z już wspomnianych powodów nie ma takiej potrzeby. Osoba, która pierwotnie ci to powiedziała, dała ci złą radę. Mogło być źle, „ma to sens w kontekście źle skonfigurowanego systemu naszej organizacji”, ale w tym przypadku jego zadaniem było to naprawić. Wciąż zła rada.

użytkownik3131341
źródło
1
Nie jestem pewien, czy „musisz natychmiast przestać to robić, ale możesz kontynuować robienie tego w innym miejscu” ma sens.
underscore_d
3

Czy „Nie poprzedzaj tabel tabelą tbl” naprawdę stanowi problem?

Odnośnie systemu? Nie. W odniesieniu do innych ludzi? Może. Możesz wygenerować dużo nienawiści.

Ja osobiście nie prefiksuję tabel, ale robię to na innych obiektach, takich jak widoki, procedury składowane, funkcje itp.

Joe
źródło
1

Chciałbym powiedzieć, proszę, przestań to robić. Stało się to w przeszłości, ale kontynuując to, zachęcasz nowych ludzi, którzy przychodzą do twojego środowiska, aby myśleli, że to lokalna konwencja i kontynuują. Ale nie będą po prostu kontynuować, zrobią to nieco inaczej

Podczas przeszukiwania bazy danych dla określonego elementu, a nie tylko ja otwieram eksplorator obiektów i myślę, że przewinę do niego, wiesz, że jest to alfabetycznie. To jest, dopóki prefiksy nie zaczną mętnieć wód, a ja mam tblname, tbl_name, tbname, t_name i tysiące innych odmian, naprawdę trudno jest znaleźć tabelę, o której wiesz, że jest już tabelą

Podobnie poprzedzając wszystko vw_ lub sp_, ktoś wejdzie i dostaniesz SPname, spname, s_p_name. Usuń wszystkie prefiksy, oprogramowanie wie, co to jest pozycja, jeśli naprawdę musisz wiedzieć, użyj sufiksu. NameOfMyView_v, NameOfMyProc_sp. znacznie łatwiej wyszukiwać wizualnie

Ale co, jeśli przeszukujesz długo przechowywany proces i nie możesz łatwo powiedzieć, co to jest widok proc lub stół? Są duże szanse, że i tak zostaną one aliasy, a nawet jeśli nie, sufiks przyjdzie ci z pomocą

Nie bój się zmieniać tego, co robisz, a jeśli wejdziesz do środowiska, w którym konwencje nazewnictwa zostały już zastrzelone, nie bój się wdrożyć własnych i zacznij zmieniać rzeczy na lepsze. Dopasowując istniejący chaos, nie ma szans, aby uczynić go mniej mylącym, tylko sprawiając, że będzie to więcej

zarost
źródło
-3

Jeśli muszę wymyślić zaletę posiadania przedrostka „tbl”, to w obecnym SSMS, z inteligencją, mogę po prostu pisać

select * from tbl

a następnie znajdź potrzebną nazwę tabeli (zakładając, że nie mam pojęcia o dokładnej nazwie tabeli). To praca jednoetapowa. Oczywiście, zawsze możemy znaleźć nazwę tabeli, wykonując dodatkowe kroki, ale powiedziałbym, że w przypadku prefiksu „tbl” jest to JEDEN krok i dlatego zawsze wolę prefiks (niekoniecznie „tbl”) w mój własny projekt pracy domowej.

Edycja : (Po tylu głosach w dół, nadal uważam, że warto wskazać pewne niszowe zalety nadania określonego prefiksu konkretnej kategorii obiektów na serwerze sql). Wygląda na to, że nikt nie narzeka na prefiks procedury / funkcji / widoków przechowywanych, ale zawsze jest to argument z tabelami. (Dla mnie w prawdziwym świecie nie przejmuję się tym, czy podajemy prefiks, czy nie).

Pamiętam, że w serwerze SQL 2005 dni było wymaganie, aby znaleźć tabele, w których przechowywane są procedury / widoki z prefiksem nazw tabel, to było takie łatwe zadanie z wyrażeniem regularnym / C #. (Tak, wiem, że były inne sposoby, tutaj nie ma argumentów).

Moja kariera rośnie wraz z czytaniem wielu artykułów / artykułów o najlepszych praktykach, ale widziałem także wystarczające wyjątki od prawie każdej „najlepszej praktyki” w ten czy inny sposób w różnych scenariuszach. Dlatego zawsze mówię sobie i innym DBA, oceniam zgodnie z wymogami biznesowymi, „najlepsza praktyka” ma swoje miejsce na pewno, ale można ją rozpatrywać tylko w kontekście naszego własnego środowiska.

jyao
źródło
2
Bardzo łatwo jest otworzyć menedżera obiektów w SSMS, aby zobaczyć wszystkie nazwy tabel negujące tę „przewagę”. Co więcej, jestem prawie pewien, że twoja sztuczka będzie działać poprawnie tylko podczas odwoływania się do tabeli bez schematu, który może prowadzić do innych problemów. Nie wiem, czy te lub inne powody wpłynęły na decyzję ludzi o głosowaniu w dół, ale moim zdaniem wydają się one obiektywnymi przyczynami do głosowania w głosowaniu.
Erik,
Muszę powiedzieć, że użycie przedrostka „tbl” ma w moich oczach przewagę niszową. Tak, możesz wpisać schemat, aby wyzwolić inteligencję, ale jeśli w moim środowisku testowym mam tylko [dbo] jako mój schemat? Właściwie w moim projekcie często lubię używać podkreślenia „_” (ale teoretycznie to samo co „tbl”). Wszystko ma dwie strony jako monetę, tak jak niektórzy ludzie wolą długie nazwy tabel, podczas gdy inni wolą skróty. To pytanie o prefiks wywołuje wiele interesujących dyskusji. Moim zdaniem, dopóki twój argument ma sens, jest to dobry argument.
jyao
6
Uważam, że opinie negatywne po prostu pokazują, że ten argument jest stosunkowo słaby. Jeśli kiedykolwiek będziesz musiał zmierzyć się ze scenariuszem opisanym przez @billinkc w jego odpowiedzi, skończysz z widokiem, który ma taki sam przedrostek jak tabele. Oprócz tego, że byłoby to mylące, jak już wspomniano, zawsze będziesz wyświetlać ten widok na liście sugestii podczas wpisywania prefiksu. Gdy będziesz mieć wiele takich widoków, korzyść, o której mówisz, nie będzie już tak widoczna, jak ją malujesz.
Andriy M,
-3

Rozważmy dbo.Uservs dbo.tUser. Teraz wyobraź sobie, że chcesz znaleźć wszystkie miejsca w kodzie, w których używana jest ta tabela. Która wersja sprawia, że ​​jest to łatwiejsze (a nawet możliwe?) Słowo „użytkownik” może mieć wiele fałszywych trafień, takich jak nazwy zmiennych, w komentarzach itp.

Tego nie widziałem w żadnej innej odpowiedzi, ale jestem deweloperem-DB-DBA, więc może inni nie musieli pracować nad starszym kodem, w którym zapytania mogą być osadzone w aplikacji, i nie wszystkie zapytania w pełni kwalifikują odwołania do schematu i podobne rzeczy. (Nawet jeśli wszystko jest w pełni wykwalifikowany, trzeba znaleźć dbo.Useri [dbo].[User]a dbo.[User]i tak dalej). Lub wersje baz danych, w których „informacje o zależnościach” stają się nieaktualne i są niedokładne (np. Starsze wersje MS-SQL)

Tak więc, przy niektórych projektach, nad którymi pracowałem, które są tak pomieszane, nakazałem prefiks a tlub v(tbl_ robi się głupi), aby uczynić go bardziej selektywnym wyszukiwanym terminem.

W późniejszych projektach, takich jak SQL Server Data Tools (cześć, Znajdź wszystkie referencje) i dostęp do bazy danych wyłącznie przez warstwę ORM, nie ma żadnego narzędzia, ponieważ znalezienie wszystkich zastosowań tabeli jest banalne (podobnie jak jej zmiana nazwy!)

Mark Sowul
źródło
Daj nam kontynuować tę dyskusję w czacie .
Mark Sowul,
-4

Każda strona ma swoje zalety i wady. Decyzje w sprawie konwencji, których należy przestrzegać, zależą wyłącznie od decyzji zespołu lub firmy.

My, na przykład, korzystamy z tblkonwencji. Głównym powodem jest to, że wiemy w skryptach, co możemy, a czego nie powinniśmy robić. Mamy różnorodne projekty i ludzi, którzy wskakują, nie znając schematu na pamięć. Nasze tabele mają logiczne nazwy, więc łatwo jest znaleźć swoją drogę podczas pisania skryptów. Robiąc to, kiedy znajdujemy stolik, od razu wiemy (poprzez IntelliSense), że jest to stolik. Można argumentować, że dodanie prefiksu nie dodaje dużego kontekstu. Jednak usunięcie go oznacza, że ​​nie ma kontekstu.

Jedyną prawdziwą zaletą nieużywania prefiksu jest zamienność. Twierdziłbym jednak, że jest to potencjalnie niebezpieczna sytuacja. Jasne, twoje skrypty i zapytania się nie psują, ale być może zaczynasz zbytnio polegać na tym fakcie, a niektóre rzeczy po prostu nie działają z widokami lub są odradzane.

Ostatecznie sprowadza się to do tego, co preferuje Twój zespół i jak pisze kod / skrypty.

Kevin V.
źródło
Nie rozumiem, dlaczego ludzie nie lubią uczciwych odpowiedzi. Jeśli twój zespół go używa, używaj go, ponieważ złościsz swoich współpracowników, jeśli nie, nie. Przepraszam, że tak łatwa może być odpowiedź. Jeśli pracujesz sam, po prostu rozważ zalety i zalety. Nie słuchaj mas tylko dlatego, że to masy.
Kevin V
-12

Kiedyś miałem powód, aby poprzedzać nazwy tabel słowami „tbl”. Jeśli patrzysz na listę obiektów bazy danych, możesz uruchomić to zapytanie:

select * from sysobjects

Jeśli chcesz uzyskać tylko tabele, możesz to zrobić:

select * from sysobjects where type = 'U'

Kto to pamięta? Jeśli wszystkie nazwy tabel zaczynają się od „tbl”, możesz użyć tego zapytania, które nie wymaga zapamiętywania wartości kolumny typu:

select * from sysobjects where name like 'tbl%'

Ponieważ otagowano SQL Server 2014, nie dotyczy to Ciebie, ponieważ od SQL Server 2005 możesz to zrobić w zamian:

select * from sys.tables

Nie mogę wymyślić innego powodu, by prefiksować nazwy tabel.

user2023861
źródło
12
1) Re: „ Kto to pamięta?Zapamiętywaniewhere type = 'U' nie różni się zbytnio where name like 'tbl%', szczególnie po kilkukrotnym wykonaniu tego. 2) W celu uzyskania dokładnych informacji, sys.tablesbył dostępny począwszy od SQL Server 2005: technet.microsoft.com/sr-latn-rs/library/ms187406(v=sql.90) technet.microsoft.com/sr-latn- rs / library / ms187406 (v = sql.90)
Solomon Rutzky
8
Być może nie pamiętasz, 'U'ale zawsze możesz utworzyć widok: create view all_the_tables as select * from sysobjects where type = 'U';Następnie po prostu uruchomselect * from all_the_tables;
ypercubeᵀᴹ