Witam, musze zrobic 25pol i teraz sie zastanawiam czy lepiej podzielic to na np. 2 tabele czy zrobic wszystko w jednej?

Podejdz do tego od innej strony:

Informacje o czym chcesz przechowywac, o jakich obiektach, np. Klient Towar itp.


Bo powiedzenie 25 pol nic nie znaczy.

Tak to sie ma:
prod_id == id tutaj chyba wszystko jasne
prod_o_nazwa varchar(155) Nie === nazwa jedno zdanie;)
prod_o_producent varchar(155) Nie === id producenta np. 13
prod_o_kod varchar(155) Nie === kod np. 99929393
prod_o_ilosc varchar(155) Nie === ilosc np. 100
prod_o_opis text Nie === opis produktu
prod_o_transport varchar(155) Nie === transpor np. 1 ( max 1 znak)
prod_o_montaz varchar(155) Nie === 1 lub 2 ( max 1 znak)
prod_o_foto1 varchar(155) Nie === nazwa pliku np. 1_20060613164710.jpg
prod_o_foto2 varchar(155) Nie === nazwa pliku np. 2_20060613164710.jpg
prod_o_foto3 varchar(155) Nie === nazwa pliku np. 3_20060613164710.jpg
prod_c_z_stawka varchar(155) Nie === ( max 1 znak)
prod_c_z_netto varchar(155) Nie
prod_c_z_brutto varchar(155) Nie
prod_c_s_stawka varchar(155) Nie
prod_c_s_netto varchar(155) Nie
prod_c_s_brutto varchar(155) Nie
prod_c_upust varchar(155) Nie
prod_insr varchar(155) Nie === ( max 1 znak)
prod_jezyk varchar(155) Nie === ( max 2 znak)
prod_nal varchar(155) Nie === ( max 4 znak)
prod_data varchar(155) Nie
prod_godz varchar(155) Nie

Ewentualnie jesli dane mozesz pogrupowac to dodatkowa tabele (typ -> wartosc)

Nie zauwazylem Twojej odpowiedzi.

foto mozesz przeniesc do innej tabeli wtedy bedziesz mial mozliwosc od 1 do n fotek
Ceny tez by mozna bylo, no chyba ze beda przeliczenia i troche bedzie to komplikowalo

To moze inaczej w tej bazie ma byc ok. 3000 produktów. I jak wchodze w opis jednego i z jednej tab. pobierze 25 pol to mysle ze nie bede spowalnia serwera. Ale jezeli wejde w spis ( w spisie wkorzystuje tylko 6 pol z 25) i pokaze na kazdej stronie 20 to nie spowoduje to zwolnienia? A moze

[SQL] pobierz, plaintext 
SELECT potrzebne pola FROM
[SQL] pobierz, plaintext 

wystarczy?

3000 to nie jest tak duzo. Dodaj do bazy 100 razy tyle albo i wiecej sprawdzaj koszty i czasy, a wtedy mozesz dostrajac zapytania.

dla zachowania porządku i zwiększenia możliwości proponuje więcej tabel ale logicznie zaprojektowanych.

Np cena może być zmienna i zależeć od ostatnich zakupów,

niestety sprawa się mocno komplikuje gdy tworzysz join'y dla tabel które mają miliony wierszy. 4 procesorowa maszyna się dławi przy prostch joinach na indeksach (sprawdzane były mssql , mysql i postgres ) .

Jeśli projekt w miarę mały, rozdzielaj na tabele, jeśli większy, zastanów się. Na szczęście są triggery.


i tak, dla ciebie, osobna baza produktow, osobna producentow, osobna zdjec, osobna identyfikatora zakupu, osobna sprzedazy, latwiej ci bedzie na przyszlosc modyfikowac te wszystkie dane - bardziej uniwersalne a i nauczysz się więcej.


"Ceny tez by mozna bylo, no chyba ze beda przeliczenia i troche bedzie to komplikowalo " , co takiego będzie komplikowało ? - dla programisty , trochę skomplikuje rzecz, ale do póżniejszych możliwości - okaże się idealne.