Witam,

Czy można zamiast ID które zazwyczaj jest w postaci liczb dodać id będące ciągiem znaków i liczb:



Ma to jakiś wpływ na wydajność bazy przy liczbie rekordów z takimi ID około 3tyś.

Z technicznego punktu widzenia - można. Ja jednak proponowałbym standardowy id + kolumnę z wartością z nałożonym indeksem unikalności. Jeśli będziesz miał gdzieś klucze obce do tej tabeli sprawniej będzie Ci się operowało na idkach. Generalnie jestem zdania, że zawsze powinno się stosować kolumnę id (nawet jeśli z pozoru jest zbędna). Przykładowo mając tabelę z danymi Polaków kluczem głównym mógłby być PESEL, ale ponoć nie daje on 100% pewności co do unikalności.

Dziękuję za odpowiedz.

Mam jeszcze jedno pytanie.

Projektując bazę mam jedną tabelę składającą się z 18 kolumn z parametrami. Około pięciu kolumn posiada wypełnienie w 1/4 czy jest to bardzo złe? Wiem że nie powinno się zostawiać pustych komórek gdyż wydajność bazy spada.

Przez puste rozumiem, że masz na myśli NULL? Nic złego się nie dzieje. Duża ilość pustych komórek może co najwyżej sugerować zły projekt bazy danych, ale sama w sobie nie jest czymś specjalnie złym - na pewno nie ma to znaczącego wpływu na szybkość bazy danych.

Co do dużej ilości pustych komórek to tak masz rację jest to oznaką źle zaprojektowanej bazy ale akurat w tym przypadku nie da się inaczej tego zrobić.

Dziękuję serdecznie i pozdrawiam

Jeśli są to kolumny tego samego typu to przecież można je wydzielić do osobnej tabeli. Czyli z:
tabela [id, param1, param2...]
Przechodzisz na:
tabela [id]
dodatkowa [tabela_id, param_id (czyli 1, 2...), param_value]
Dokładając nowe parametry nie dokładasz kolumny tylko wiersze. Jeśli jednak kolumny te są różne typu i nie musisz po nich wyszukiwać tylko wykorzystujesz je w PHP to możesz kolumnie param_value nadać typ TEXT, a następnie ewentualnie rzutować jej wartość na odpowiedni typ już w PHP.

@Pejot:
czy Twoja struktura ma być zasilana importami z pliku? Jeśli tak, to nie szalej z normalizacją i kluczami opartymi na INT, bo jest to potem niewygodnie.

Przykład:
Teta HR posługuje się kluczami opartymi na INT z autonumberem z daleko posuniętą normalizacją. SAP R/3 zapisuje klucze jako varchar i są na dobrą sprawę wielokolumnowe i nie jest znormalizowany przez co ma sporo null.

Podczas generowania raportów, klnę Teta HR w żywy kamień, bo nie wiem co jest co bez doklejenia kilku tabelek. Podobnie z importem danych: jedno zestawienie muszę kadrowe "posiekać" na części pierwsze, przejść na numery, zaimportować i nakombinować się przy weryfikacji.
W SAP nie występuje żaden z wwym kłopotów.

Reasumując, założenia teoretyczne nie mogą być stosowane bezkrytycznie - musisz przeanalizować scenariusze wykorzystania danych i ustalić jak będzie Tobie łatwiej.

Pozdrawiam

Michał