Dlaczego prefiksowanie nazw kolumn jest uważane za złą praktykę?

25

Według popularnego postu SO prefiksowanie nazw tabel uważane jest za złą praktykę. W mojej firmie każda kolumna jest poprzedzona nazwą tabeli. Trudno mi to przeczytać. Nie jestem pewien powodu, ale ta nazwa jest w rzeczywistości standardem firmy. Nie mogę znieść konwencji nazewnictwa, ale nie mam dokumentacji, aby uzasadnić swoje rozumowanie.

Wiem tylko, że czytanie AdventureWorks jest znacznie prostsze. W tym DB naszej firmy zobaczysz tabelę Osoba i może mieć nazwę kolumny:

Person_First_Name,
a może nawet
Person_Person_First_Name (nie pytaj mnie, dlaczego widzisz osobę 2x)

Dlaczego poprawianie nazw kolumn jest uważane za złą praktykę? Czy podkreślenia są również uważane za złe w SQL?


Uwaga: Posiadam Pro SQL Server 2008 - projekt i implementacja Relacyjnej bazy danych. Odniesienia do tej książki są mile widziane.

P.Brian.Mackey
źródło
2
Wygląda na to, że kto stworzył te reguły, nie wiedział o funkcji aliasingu.
ba__friend
@Daniel Pryden - Użyłem złych sformułowań. Pytanie zaktualizowane.
P.Brian.Mackey,
Podobny rodzaj postu tutaj stackoverflow.com/questions/465136/...
@ba__friend - Czy możesz podać mi trochę szczegółów na temat tego komentarza?
P.Brian.Mackey,
1
Najważniejszym słowem, które użyłeś, jest Standard. Jeśli zmienisz standardową praktykę, masz niespójność. Czy naprawdę uważasz, że jakakolwiek zmiana w stosunku do tej standardowej praktyki jest warta wynikającej z niej niekonsekwencji? Czy status quo jest naprawdę gorsze?

Odpowiedzi:

44

Podkreślenia nie są złe, po prostu trudniejsze do napisania. Złe jest zmienianie standardów w połowie strumienia bez naprawiania wszystkich istniejących obiektów. Teraz masz personId, Person_id itp. I nie pamiętasz, która tabela używa podkreślników, czy nie. Konsekwencja w nazewnictwie (nawet jeśli osobiście ci się nie podoba) pomaga ułatwić kodowanie.

Osobiście jedynym miejscem, w którym czuję potrzebę użycia nazwy tabeli w kolumnie, jest kolumna identyfikatora (użycie tylko identyfikatora jest antypatternem w projektowaniu bazy danych, co może powiedzieć każdy, kto przeprowadził obszerne zapytania raportowe. Zmiana nazwy jest świetną zabawą. 12 kolumn w zapytaniu za każdym razem, gdy piszesz raport.) Ułatwia to także natychmiastowe poznanie FK w innych tabelach, ponieważ mają one taką samą nazwę.

Jednak w dojrzałej bazie danych jest więcej pracy niż warto zmienić istniejący standard. Po prostu zaakceptuj to, co jest standardem i przejdź dalej, jest o wiele więcej krytycznych rzeczy, które należy naprawić w pierwszej kolejności.

HLGEM
źródło
4
To prawda, ale baza danych bez spójnego standardu nazewnictwa jest znacznie trudniejsza do wyszukania niż baza danych o złym standardzie, który jest konsekwentnie stosowany.
HLGEM,
2
Częściowo się zgadzam. Jeśli baza danych jest OGROMNA, zachowaj standard. Ale spędzam czas na czytaniu kodu, a nie na pisaniu go, a prefiksy nazw tabel wydają się przesuwać więcej hałasu. Gdybym to był ja i wiedziałbym, że mogę to przebudować w ciągu kilku dni lub tygodnia, na pewno bym to zrobił. Ale dużo czasu nie masz tego luksusu i musisz ciągle kodować produkcje, produkcje, produkcje.
programista
3
@jason, możesz złamać więcej, niż myślisz, robiąc to. Do baz danych często ma dostęp wiele rzeczy, o których programista aplikacji nie jest świadomy. Rzeczy takie jak import danych od klientów lub innych DBS i eksport do klientów i magazynów danych, inne aplikacje, raporty itp. Możesz przyzwyczaić się do czytania dowolnego standardu w ciągu kilku godzin i refaktoryzacji od zatwierdzonego standardu firmowego bez zgody na przejście na nowy standard spowoduje zwolnienie z pracy w większości miejsc. Szczerze mówiąc, chyba że baza danych jest w powijakach, lepiej jest użyć istniejącego standardu, czy ci się to podoba, czy nie.
HLGEM
7
@Jason, jestem osobą z bazy danych, wiemy, że nie mamy poczucia przygody!
HLGEM
2
Całkowicie zgadzam się z TableName.Id is an antatattern. Pracowałem w obrębie tego wzorca i bez niego na tyle długo, że mogę śmiało powiedzieć, że w
TableName
16

Argument przedrostka nazwy kolumny zapobiegałby „kolizjom” nazw podczas łączenia wielu tabel ORAZ, gdy twórca zapytania nie używa aliasów.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Oba zapytania miałyby dwie kolumny „nazwa” ( nazwa_1, nazwa_2 ) bez „informowania”, do której jednostki należy. I nigdy nie możesz być pewien wygenerowanych nazw kolumn (czy to będzie nazwa_2, czy nazwa_3, czy ...). Jeśli używasz nazwy tabeli poprzedzanie, nazwy kolumn byłoby PERSON_NAME , COMPANY_NAME więc wiesz każdą nazwę, do której jednostka należy, oraz wiedzieć, że nazwy kolumn pozostanie na stałym poziomie (jeśli zachęcając w Javie przy użyciu JDBC na przykład ).

Oba argumenty można zignorować, jeśli używasz aliasingu, ale myślę, że większość konwencji kodowania egzekwowanych w firmach wynika z tego, że wielu (młodszych) programistów nie przestrzega dobrych praktyk. W takim przypadku na przykład użycie symbolu wieloznacznego w instrukcji SELECT może powodować problemy bez prefiksu nazwy.

Jeśli chodzi o podkreślenie w nazwach tabel i kolumn, używam go szeroko, ponieważ używam tylko małych liter w nazwach i podkreślenia jako separatora. Używanie tylko małych liter pomaga odróżnić identyfikatory od słów kluczowych SQL (które wpisuję wielkimi literami):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'
Nicolae Albu
źródło
6
Chciałbym, aby wszystkie kolumny z tymi samymi informacjami w różnych tabelach miały dokładnie taką samą nazwę i że za każdym razem, gdy użyjesz więcej niż 1 aliasing tabeli, będzie to wymuszony standard. Zmęczyło mnie już zapamiętywanie, do których map patid, patientid, pat_id, id_pat lub ptatient_id.
Pieter B
1
Nigdy nie piszę zapytania produkcyjnego bez aliasingu wszystkich kolumn. Ułatwia to konserwację. Oczywiście piszę skomplikowane zapytania dotyczące raportów / eksportu z maksymalnie 10-20 złączeniami i 30-50 kolumnami, a sześć miesięcy później trudno jest zapamiętać, z której tabeli pochodzi ta kolumna.
HLGEM
8

Dodanie tego rodzaju prefiksów do nazw kolumn utrudni ewolucję tabeli. Na przykład: jeśli ostatecznie zdasz sobie sprawę, że chcesz / musisz zmienić nazwę tabeli, będziesz musiał zmodyfikować całą jej strukturę tabeli (tj. Nie tylko nazwę tabeli, ale nazwę wszystkich jej kolumn). Utrudniłoby to również aktualizację indeksów tabeli i kodu klientów, którzy ją sprawdzają.

Sergio
źródło
4

Istnieją wyjątki, jeśli zostaną użyte rozsądnie (zgodnie z odpowiedzią Patricka Karchera na Twój link) dla popularnych nazw kolumn (zwykle tylko identyfikator, czasem nazwa), które byłyby zbyt dwuznaczne .

Inną najlepszą praktyką jest zawsze kwalifikowanie kolumn i obiektów w zapytaniach. Tak więc prefiksy kolumn stają się dyskusyjne i zaśmiecają kod.

Porównaj je: co jest najłatwiejsze dla oka?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person
gbn
źródło
3
Zdecydowanie pierwszy ... :)
ErikE,
3
Co SELECT name, salary FROM dbo.Person? : P
cHao
1
@ cHao: spróbuj utworzyć widok Z SCHEMABINDINGIEM na ten temat ...
gbn
@gbn: Działa dobrze dla mnie. CREATE VIEW [dbo].[vwMeritPercentage] with schemabinding AS SELECT [Performance Score] as dblMinScore, ISNULL(( SELECT TOP 1 [Performance Score] FROM dbo.Budget b WHERE b.[Performance Score] > budget.[Performance Score] ORDER BY [Performance Score] ), 100.00) as dblMaxScore, [Merit Minimum] as dblMinPercentage, [Merit Midpoint] as dblBudgetPercentage, [Merit Maximum] as dblMaxPercentage FROM dbo.Budget;
cHao
1
Odpowiednia dokumentacja ( msdn.microsoft.com/en-us/library/ms187956(v=SQL.105).aspx ): „Gdy używasz SCHEMABINDING, select_statement musi zawierać nazwy dwuczęściowe (schema.object) tabel, widoki lub funkcje zdefiniowane przez użytkownika, do których istnieją odniesienia. ” Zauważ, że kolumny nie wymagają nazw kropkowanych (chyba że są one wymagane do rozwiązania niejednoznaczności w zapytaniu) ... tylko tabele, widoki i funkcje.
cHao
3

Ogólnie rzecz biorąc, wydaje się, że nie ma żadnych wszechobecnych standardów. Pytanie, z którym się łączysz, zawiera kilka wysoko głosowanych odpowiedzi o całkowicie odmiennych konwencjach. Oczywiście wszyscy będą bronić własnych standardów, a o wiele ważniejsze jest utrzymanie spójnych konwencji w projekcie.

To powiedziawszy, prefiksowanie nazw kolumn wydaje się przesadą. Wiesz już, z jaką tabelą pracujesz, a sytuację z dwiema kolumnami z różnych tabel o tej samej nazwie można łatwo rozwiązać za pomocą aliasów tabeli lub kolumny.

Dan Simon
źródło
2

W TSQL możesz odwoływać się do pól w postaci TableName.FieldName, jeśli chcesz uniknąć dwuznaczności, więc dodanie nazw tabel do nazw pól faktycznie odbiera czytelność, czyniąc ją TableName.TableName_FieldName lub podobną. Myślę, że używanie podkreślników lub nie jest bardziej osobistym wyborem. Wolę CamelCase i używam _, gdy chcę dodać sufiks lub podobny, np. TableName_Temp, ale to tylko ja.

Ben Robinson
źródło
2

Kiedyś pracowałem nad systemem, w którym postanowiliśmy użyć krótkich kodów do prefiksu kolumn. Pola PK używały „pełnej nazwy tabeli” jako prefiksu, a wszystkie inne kolumny używały 2-4 znaków konsekwentnie jako prefiksu. Każda kolumna używała również domeny danych jako sufiksu. Jeśli zrobione konsekwentnie, może być bardzo ładne i czyste. Bzdura, że ​​taki lub inny standard nazewnictwa implikuje niechlujne kodowanie. Ważna jest obecność spójnego standardu. Widziałem wiele baz danych, które są niespójne, ponieważ nie ma jasnego standardu, a to bardziej niż cokolwiek innego wskazywałoby mi, że mogą wystąpić problemy w strukturach danych. Jeśli projektant bazy danych nie może nawet konsekwentnie nazywać obiektów i ich dzieci,

Tomek
źródło
1

Prefiksowanie to zła praktyka, ponieważ powoduje problem, któremu ma zapobiegać. Jak już wspomniano, bardzo trudno jest odczytać prefiksowane kolumny. Jeśli skończysz ze zduplikowanymi nazwami kolumn w zapytaniu, w którym łączysz dwie tabele, możesz rozwiązać ich, lub jest to widok, procedura składowana lub tabelaryczna funkcja zdefiniowana przez użytkownika, która robi to za Ciebie, jeśli ciągle dołączasz do określonych tabel.

Jeśli chodzi o użycie podkreślenia w nazwie tabeli, jest to argument religijny. W końcu jeśli poprawi widoczność i ułatwi to. Zasadniczo nigdy nie miałbym spacji ani tabel w nazwie kolumny lub tabeli. Mogę jednak zrobić wyjątek dla tabel lub widoków, które były używane tylko przez pakiet raportowania lub eksportowane do pliku CSV.

Justin Dearing
źródło
1

Wiele baz danych ma ścisłe ograniczenia liczby znaków w nazwie kolumny (tj. Oracle).

Jeśli pracujesz z bazą danych, która pozwala na długie nazwy kolumn, ale później zdecydujesz, że chcesz przenieść tę strukturę do innego systemu bazy danych, prefiksy zwiększą szanse, że nazwy kolumn będą nieprawidłowe.

Chociaż pracujesz teraz z SQL Server, nikt nie jest w stanie przewidzieć przyszłości i możliwe, że twoje oprogramowanie będzie musiało działać w wielu bazach danych w przyszłości.

Britt Wescott
źródło
0

Rozważ napisanie słownika danych (lub „rejestru”). Rozumiem przez to dokument zawierający wszystkie elementy danych w twoim modelu: nazwę, opis itp. Powinien być niezależny od implementacji modelu, np. Nie powinien wymieniać nazw tabel. Jak ujednoliciłbyś nazwy, takie jak „ID”, „Typ” i „Kod”?

Jednym z podejść jest przestrzeganie wytycznych międzynarodowej normy ISO / IEC 11179 - w końcu po co wymyślać koło? Podstawowa struktura to:

[Object] [Qualifier] Property RepresentationTerm

z ogranicznikami między elementami: SQL nie działa dobrze ze spacjami w nazwach kolumn, a podkreślenie działa dobrze wizualnie.

Mam wrażenie, że ktoś w Twojej organizacji próbował zastosować się do tych wskazówek, gdy wymyślił nazwy elementów, takie jak Person_Person_First_Name.

Przykład, który chciałbym pokazać, to słownik danych brytyjskiej służby zdrowia Nation Health Service (NHS) .

Więc nie sądzę, że konwencja nazewnictwa, przy której musisz pracować z dźwiękami, jest zbyt zła.

Podczas implementacji, np. W SQL, niektórzy ludzie lubią pomijać podelementy Object, Qualifier i Property, gdy nazwa tabeli zapewnia kontekst, np. person_first_nameStaje się first_namew Persontabeli itp. Jednak ogólna zasada, że ​​element danych nie powinien zmieniać swojej nazwy po prostu ze względu na swoje położenie w modelu fizycznym wydaje się być dobry. Każdy, kto uważa, że ​​przestrzeganie tej zasady nie jest dobrym pomysłem, powinien otrzymać zadanie udokumentowania wszystkich używanych przez siebie odmian nazw :)

Ładne streszczenie ISO 11179 znajduje się w książce Styl programowania Joe Celko , w tym dowody na preferowanie podkreślników jako ograniczników w nazwach kolumn.

oneedaywhen
źródło
0

Niektórym łatwiej jest w kodzie wiedzieć, z której tabeli pochodzą dane, jednak jeśli mówimy o systemie obiektowym, powinieneś użyć kontekstu nazwy, aby wiedzieć, skąd pochodzi, w tym przypadku nazwa tabeli.

Osobiście prefiks nazwy tabeli wskazuje, że programiści nie są zbyt wykwalifikowani, a gdy zagłębisz się głębiej, znajdziesz wiele innych złych konwencji kodowania i jeśli będę musiał zgadywać, że aplikacja ma zbyt wiele tabel, jest wadliwa itp.

Bill Leeper
źródło