Czy długość nazwy pola (kolumny tabeli) w bazie danych ma znaczący wpływ na wydajność połączeń z bazą danych?

Pytam, bo chciałbym używać zamiast

d_pref_dzial_on

np.

dzial_ustawienia_dzial_wlaczony

Mowa tu o ciągach długości maksymalnie 40-50 znaków.

No wiesz, niby to zawsze więcej do transmisji. Ale to będą ułamki sekund.

Poza tym, dużo lepiej będzie, gdy:

• będziesz używał angielskich nazw kolumn
• konsekwentnie nadawał nazwy zmiennych, np. jak masz tabelę działy, to kolumna będzie miała tylko enabled, a nie taki tasiemiec, którego znaczenie można wywnioskować z kontekstu rekordu i nazwy tabeli

No chyba, że masz źle zaprojektowaną bazę, to wtedy się nie dziwię.

Tabela nie nazywa się działy tylko elementy, a jednym z elementów jest dział. To, że wiele pól rozpoczynać się będzie od prefiksu dzial_ nie oznacza, że baza jest źle zaprojektowana. Oznacza jedynie tyle, że w jednej tabeli możesz mieć kilka typów danych i chcieć je wzajemnie sortować.

Załóżmy, że masz tabelę części, a w niej kilka typów danych silnik, koło, kierownica. Mają one pewne wspólne cechy jak waga nazwa, data dodania itp. Mają jednakże również zupełnie różne względem siebie właściwości i tak masz kolumny

typ danych (silnik, koło, kierownica)
nazwa
waga
data dodania
data ostatniej modyfikacji
silnik_moc
silnik_pojemnosc
kolo_srednica
kolo_felga
kierownica_kolor
kierownica_material
kierownica_wspomaganie

Umieszczasz to w jednej tabeli, ponieważ to tak naprawdę pozwala najszybciej sortować dane.

Można to podzielić na kilka tabel, ale aby sortować lub filtrować te dane trzeba by korzystać z JOINÓW, a o ile mi wiadomo JOIN powoduje, że każdy pobierany rekord z tabeli A powoduje przeszukanie całej tabeli B (do moment u natrafienia na rekord zbieżny).

Nie muszę tworzyć zbiorczej tabeli tymczasowo zbierającej te dane, bo wszystko już jest w jednej wspólnej tabeli. To zwiększa możliwości. Robisz sobie filtry: pokaż tylko koła, pokaż tylko kierownice, pokaż tylko silniki, albo pokaż wszystkie części, ale koła ogranicz do takich o określonej średnicy itp.

Powyższe zakłada, że tych elemenów będzie NIE WIĘCEJ niż 3. Nie są to produkty sklepu, przykład części nie jest tu zbyt dobry, ale załóżmy, że części są TYLKO I NIE WIĘCEJ ORAZ WYŁĄCZNIE NIE MNIEJ NIE WIĘCEJ JAK WŁAŚNIE TRZY :- ).

JOINY przecież marnują czas pracy, zbędnie x razy przeszukują wiele tabel. To jakby próbowac rozdzielić imię i nazwisko użytkownika na dwie tabele tylko dlatego, że jedno jest imieniem, a drugie nazwiskiem i nie są tym samym.

Nie chcę używać angielskich nazw kolumn tak samo jak nie używam angielskich nazw zmiennych itp.

Ktoś powiedział, że anglojęzyczne nazwy zmiennych i kolumn są ok i Ty się tym zasugerowałeś, natomiast sposób nazewnictwa zmiennych nie ma kompletnie żadnego wpływu na jakość, wydajność i elastyczność kodu. Ważniejsze jest dla mnie to czy jak użyję 50 znaków zamiast 15 w nazwie kolumny tabeli zauważę znaczy spadek wydajności zapytań przy powiedzmy kilku tysiącach rekordów.

Oczywiście wyprzeć się możesz stwierdzeniem, że to ułatwi czytanie kodu innym niekoniecznie polskim programistom, ale tego typu sytuacje z reguły nie zdarzają jeśli nie programujesz jako pracownik. Będąc pracownikiem podlegasz regułom, a bo to wspólnik anglik, a bo inny koder anglik, a bo to manager nie z polski. Pracując na własne konto samodzielnie definiujesz reguły.

To było tylko przykładowo. W każdym razie - może masz po prostu nierelacyjnie...?



A normalizacja?


I Twój problem, potem się natkniesz na taką sytuację, w której będzie się ciężko przestawić.


Nie zasugerowałem. Po prostu tak się przyjęło i już. Sprawdź w serwisach, w których skupiani są programiści z wielu państw i porażająca większość używa języka angielskiego pomimo, że to nie jest to ich rodzimy.


Polskie nazwy zmiennych są właśnie Twoją regułą. Większość dokumentacji jest w języku angielskim, kod tak samo, obiekty w MVC też.

I tu nie ma nic do tego, że Anglik. Tak, jak językiem medycyny/prawa jest łacina, tak językiem informatyki - angielski. I może Ci się to podobać lub nie, Twoja sprawa.

No załóżmy, że elementem jest samochód, który ma mnóstwo właściwości. Jedne dotyczą kół, inne silnika itp. W ten sposób jeden rekord to powiedzmy 90 pól właściwości. Spoko rozbijesz to na 10 tabel po 9 pól każda, gdzie w każdej tabeli bedziesz miał cechy odpowiednio kół, silników itp. Nawet jeśli to it ak szukając, określając filtry bedziesz musiał to złożyć do kupy. Zwłaszcza w momencie kiedy wszystkie dane wyświetlane przy samochodzie są na raz, a nie wybiórczo :- ). Relacje są względem zdjęć i innych elementó. Informacje o zdjęciach są powiedzmy w innej tabeli przyporządkowującej je do konkretnego samochodu.

No dobra, a co mnie obchodzą programiści skupiani w jakichś serwisach internetowych? Jak Bill powie WINDOWS jest BE i 90 % programistów to potwierdzi to ja też mam

Widzisz niestety nie zawsze da się to tak ładnie rozwiązać jakbyś chciał. Weź choćby Framework ze stajni Zend. Zajefajny spsób analizy adresu wpisywanego w przeglądarce. I teraz tworząc aplikację po polsku tworzysz sobie zmienną FRAZA dla wyszukiwarki.

Masz taki adres: http://strona.pl/aktualnosci/listaAktualnosci/fraza/nowa/

W psudotablicy GET dostajesz zmienną o nazwie fraza. Po co? By użytkownik końcowy otrzymał maksymalnie ergonomiczny serwis, a więc patrząc na adres strony wiedział do czego się on odnosi. Zmusza Cię to do translacji zmiennej polskiej na angielską w aplikacji. To samo tyczy sie nazw kontrolerów, akcji itp. Zmuszasz się tym samym do myślenia w dwóch językach, a to znacznie obniża wydajnośc kodowania. Piszę aplikacje dla polakow, więc są po polsku. Będę pisał dla amerykanina napiszę mu po angielsku. Będzie chciał ktoś dokumentację po angielsku, dostanie ją. Tu nie ma problemu. Wolę maksymalizować wydajnośc kodowania niż zbędnie uniwersalizować kod.

Ja stawiam na jakość aplikacji od strony użytkownika końcowego, a nie od strony kodera, bo aplikacja nie jest dla kodera tylko użytkownika końcowego. No chyba, że robimy mierną ergonomię jak w przeogromnej większości serwisów w sieci.

Ale jeśli kiedyś przyjdzie Ci rozwijać aplikację, czy dodawać nowe cechy, to będziesz miał już lekki problem.

Dodanie nowego rekordu jest znacząco krótsze niż kolumny w zapełnionej tabeli.