Odnosnie optymalizacji struktury bazy - proponowalbym zatrudnic DBA (Database Architect) do zaprojektowania bazy. Wiadomo ze wymagania sie zmieniaja ale z doswiadczenia powiem, ze najgorsze co mozna miec to baze ktora zmienia sie i rozrasta w sposob organiczny, czyli jak cos nowego trzeba to sie dodaje kolumny do tabel itd... po 4-5 latach calos nie bedzie nadawac sie do jakiejkolwiek obslugi i dodanie 1 linii kodu czy nowego search'a bedzie pochlaniac miesiac pracy dla 4-osobowego zespoly - znam to z praktyki...
Co do struktury tabel - pakowanie calosci do 1 tabeli zaprzecza calkowicie relacyjnemu modelowi baz danych. Dane powinny byc zatomizowane - jedno pole, jedna wartosc... Kategoria - ok, tylko nie zapisana razem z firma ale w osobnej tabeli wykaz kategorii. Do ktorej kategorii nalezy firma? Tez nie w tabeli opisujacej firme tylko w osobnej tabeli laczacej...
Kod:
CREATE TABLE firmy (id unique serial, nazwa, adres, telefon, www, email, fax... )
CREATE TABLE branze (id unique serial, nazwa, kod, id_rodzica)
CREATE TABLE firmy_branze (firma_id, branza_id);
SELECT firmy.nazwa as nazwa, firmy.adres as adres ... branze.nazwa FROM firmy, branze WHERE firmy_branze.firma_id=firmy_branze.branza_id and firmy.nazwa like '$szukaj';
W ten sposob jestes elastyczny bo kto powiedzial ze firma musi siedziec w jednej branzy np, kto powiedzial ze firma musi miec 1 telefon, kto powiedzial ze musi byc 1 notatka od klienta - jak niby chcialbys to zalatwic majac wiekszosc pol w 1 tabeli?
5000 rekordow to jest doslownie nic... Do niedawna pracowalem na bazie ktora miala ponad 20mln rekordow i jedna tabela (transakcje) zajmowala ponad 40GB... a to tylko dla tego ze system rosl w sposob 'organiczny' i byl tam jeden wielki bajzel. Staraj sie tego uniknac albo oddaj system klientowi i zmien email, adres domowy, telefon itd... po prostu zniknij, bo nigdy nie opedzisz sie od problemow.