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

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?

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.

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%'

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

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

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.

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.

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,

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.

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.

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.

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.