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ą.

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.

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.

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.

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? `

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!

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ę.

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

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?

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 .

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.

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.

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ść.

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.

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.

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.

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

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.

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!)

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.

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.