Czy istnieje powód, aby używać wyjątkowo skróconych nazw tabel?

Używamy konfiguracji bazy danych z aplikacji dostawcy, która ma strasznie trudne do odczytania nazwy tabel bazy danych i nie ma dokumentacji na temat tego, gdzie są przechowywane. Rozumiem, dlaczego ktoś może chcieć zaciemnić swoją strukturę tabel w zastrzeżonej aplikacji, ale jednym z punktów sprzedaży tej aplikacji (Planowanie zasobów przedsiębiorstwa) była jej możliwość dostosowania.

Nazwy tabel są takie jak aptrx (transakcje płatne na rachunkach) i apmaster_all (co ciekawe, to jest tabela dostawców). Jest to niezwykle złożona baza danych, więc zastanawiałem się, czy konwencja miała jakąkolwiek logikę, czy była po prostu celowo zaciemniona.

Według mojej najlepszej wiedzy długość nazwy tabeli nie wpłynie zauważalnie na wydajność, prawda? Baza danych jest bardzo złożona (setki tabel), więc sortowanie ma sens, ale nie mogę sobie wyobrazić, dlaczego AccountsPayableTransactions nie jest lepsza niż aptrx ...

Oracle od dawna ma ograniczenia dotyczące nazw tabel wynoszących 30 znaków. Podejrzewam, że jest to starszy problem oparty na oryginalnym 16-bitowym środowisku.
Długość nazwy tabeli może mieć niewielki wpływ na wydajność, ponieważ wszystkie nazwy muszą być przechowywane w słowniku danych, a także analizowane pod kątem zapytań, ale nie sądzę, aby można było zmierzyć trafienie.

Ważniejszym efektem krótkich nazw tabel jest to, że ciężko z nimi pracować. Ja też muszę utrzymywać schemat korporacyjnej bazy danych o krótkich nazwach. Nie ma dobrego powodu, aby mieć krótkie nazwy tabel. Łatwość konserwacji przebija zaciemnienie lub stare nawyki DOS za każdym razem.

Wydaje mi się, że są jeszcze dwie rzeczy do powiedzenia lub rozwinięcia:

1. Nazywanie rzeczy nie jest tak trywialne, jak się wydaje

   Istnieją tylko dwa trudne problemy w informatyce: unieważnienie pamięci podręcznej i nazywanie rzeczy. Phil Karlton

2. Podczas gdy krótkie pozbawione znaczenia nazwy są zawsze złe, długie nazwy nie zawsze są dobre - nasze mózgi mają wbudowany próg tl; dr, który jest zaskakująco niski. Zwykle wystarcza 30 znaków , ale wolę, aby RDBMS pozwalał na więcej w wyjątkowych przypadkach, gdy tak nie jest (i podobnie jak w języku, dłuższe nazwy są bardziej przydatne w przypadku rzeczy, o których nie rozmawiamy tak często - takich jak nazwy ograniczeń i krótsze nazwy są bardziej przydatne w przypadku tabel, które stale wyszukujemy)

Zawsze kusi mnie, aby spędzać zbyt mało czasu na wyborze imion i zawsze tego żałuję, jeśli to zrobię - zmiana imion zdarza się rzadko

Lenistwo. IntelliSense i opcje innych firm sprawiają, że pisanie jest naprawdę trudnym usprawiedliwieniem. Wolałbym, żeby te imiona zawierały sensowne i czytelne słowa.

Nazwy tabel są takie jak aptrx (transakcje płatne na rachunkach) i apmaster_all (co ciekawe, to jest tabela dostawców). Jest to niezwykle złożona baza danych, więc zastanawiałem się, czy konwencja miała jakąkolwiek logikę, czy była po prostu celowo zaciemniona.

Dobrze znane skróty są zwykle lepsze niż pisownia. Kiedy skrót jest dobrze znany niektórym ludziom, ale nie dość, przestajemy nazywać go skrótem i zaczynamy nazywać go kodem.

Skróty oszczędzają miejsce na platformach, które mają ścisłe ograniczenia, chociaż jest to obecnie mniej ważne niż 30 lat temu. (Wydaje mi się, że pamiętam pracę nad systemem z lat 80., który ograniczył cię do 6 lub 8 znaków dla nazwy tabeli).

Skróty zwykle ułatwiają czytanie nazw tabel i kolumn, pod warunkiem, że jest ono dobrze wykonane. Gdybym cały dzień pracował nad kodem dla AP, wolałbym czytać nazwy kolumn takie jak „ap_trx.inv_num” niż „rachunki_płacalne_transakcje.invoice_number”. (Lubię podkreślenia.) Wpisywanie długich nazw nie stanowi większego problemu w dobrym edytorze tekstu.

W systemach księgowych zarówno „ap”, jak i „trx” są dobrze znanymi skrótami. Inne obejmują „ar”, „gl” i „gj” dla należności, księgi głównej i dziennika ogólnego.

W dobrze zaprojektowanym systemie, gdybym znalazł transakcje do zapłaty w tabeli o nazwie „aptrx”, mam nadzieję znaleźć transakcje do zapłaty w artrx, transakcje w księdze głównej w gltrx i tak dalej. Uważam, że „apmaster_all” jest trochę zagadkowe, ale gdybym również znalazł „armaster_all”, zakładam, że pierwszy posiadał wszystkich dostawców (w przeciwieństwie do aktywnych lub nieaktywnych dostawców), a drugi podobnie - wszystkich klientów.

W innych domenach problemowych znajdują się inne dobrze znane skróty. W adresowaniu znajdziesz skróty, takie jak „adres” dla adresu, „st” dla ulicy, „usps” dla usługi pocztowej Stanów Zjednoczonych, „ups” dla usługi United Parcel Service, „cty” dla hrabstwa, „zip” dla poprawy strefy Kod i tak dalej.

Nie nazwałbym tego zaciemnieniem. Gdyby płatne transakcje były przechowywane w tabeli o nazwie „cdrs21”, nazwałbym to zaciemnianiem. (Chociaż kiedyś pracowałem dla firmy, która nazwała wszystkie swoje moduły asemblera w ten sposób. Ograniczenia znaków, a nie zaciemnianie).

Ale przydatne bazy danych rosną i pojawia się problem, gdy bazy danych stają się duże. Gdy dodajesz domeny problemowe do swojej bazy danych, napotykasz sytuacje, w których zderzają się dobrze znane skróty. Jeśli masz do czynienia z mediami, wówczas „ap” może również oznaczać skrótem „Associated Press”, „alternatywna prasa” lub „awans”. Kiedy tak się dzieje, czas porzucić skróty lub przejść na kody. Im większa organizacja (i większa baza danych), tym częściej znajduję kody.

Po prostu wtrącam się do historii z „moim bogiem, gogle, nie robią nic dla tej okropnej konwencji nazewnictwa”. Zespół zarządzania danymi w moim ostatnim środowisku stwierdził, że powodem używania skróconych nazw tabel było ograniczenie DB2 (mieliśmy DB2 na Z / OS i SQL Server) 18 znaków dla tabel i kolumn. Natychmiast zauważyłem, że jest to niedokładne z dokumentacją ze strony IBM. Następnie stwierdzili, że jest to problem COBOL (tak, aktywnie opracowano COBOL) na wypadek, gdyby trzeba było porozmawiać z bazą danych, która została następnie odrzucona przez dżokejów MF. Wreszcie, ich odpowiedzią było, że to nasz standard publikowania.

Zwróciliśmy się do komitetu normalizacyjnego o zwiększenie długości z 18 do 32 znaków i otrzymaliśmy ograniczenie do 30 znaków. Spowodowało to przejście tabel z bezużytecznych nazw „SR_M_DLY_ADV_PRD_S” na „IDX_FDSHRCLAS_LIF_RTRN_STATS_X” FML

Tak więc, na podstawie mojego kilkunastoletniego doświadczenia, skrócone nazwy tabel nie dają wymiernych korzyści i skutkują wyższymi kosztami rozwoju i utrzymania, ponieważ zawsze muszę odwoływać się do słowników danych, aby przetłumaczyć śmieci na ekranie na znaczący identyfikator. Które można skontrastować z logicznie nazwanymi jednostkami, z którymi pracowałem i które w większości mogą odtworzyć z pamięci, ponieważ zostały intuicyjnie nazwane.

To nawyk (zgadzam się z Kevinsky). Była to reakcja na niektóre stare (może istnieć) problemy z ograniczeniem (długość nazwy, odstęp między słowami o złożonych nazwach, wielojęzyczność itp.) Systemu operacyjnego (na przykład DOS, Windows) i oprogramowania, które nie obsługiwało takich nazw. Doświadczeni ludzie powiedzieli: „Zrób to (użyj krótkich i oddzielonych podkreśleniem nazw), a wszystko będzie dobrze”.

Lubię używać opisowego nazewnictwa z wyżej wymienionych powodów przez plakaty.

Ale jest też inna korzyść. Na przykład w przypadku opisowego nazewnictwa pozwala na użycie nazw zagnieżdżonych. Załóżmy, że masz tabelę o nazwie Pracownik. Jeśli masz relację z inną tabelą, może ona nosić nazwę EmployeeAddress. Lub Dział Pracownika. Przy tajemniczym, skasowanym nazewnictwie jest to prawie niemożliwe.

Zależy od stopnia skomplikowania podstawowych definicji każdej kolumny. Myślę, że ludzie leniwie zarządzają metadanymi, kiedy widzą tego rodzaju bardzo opisowe nazwy kolumn, a nawet są to w rzeczywistości niepełne opisy. Równie dobrze możesz zapytać, dlaczego coś skracasz.