Chciałbym was poradzić się co do bardziej optymalnego utworzenia bazy danych. Chce dodać bazę zawierającą części która każda z nich posiada wiele różnych parametrów i wytycznych, które raptem się mogą składać na utworzenie dla każdej pojedyńczej części po ok. 50 kolumn w tabeli, lecz nie każda z nich będzie wypełniana gdyż nie musi zawierać niektórych danych. Podsumowując który z dwóch założeń tabeli będzie bardziej optymalny?

1) Utwórzyc tabele zawierającą 50 kolumn która każda będzie przydzielona do odpowiedniego parametru części.
2) Czy utworzyć dwie tabele gdzie pierwsza będzie zawierała 5 kluczowych informacji, następnie za pomocą id będzie znajdować swój odpowiednik w drugiej tabeli który zawiera wyłącznie dwie kolmny (nazwa parametru, wartość)?

Czy macie inne sposoby na optymalniejszy układ przy tak dużej ilości parametrów?

Co to te parametry? Stringi, inty czy co?
Druga tabela będzie optymalna i generalnie pozbawia Cię ograniczeń co do ilości parametrów. Tym bardziej że nie wszystkie parametry mają być wypełniane.

praktycznie wszystko tekstowe niektóre kolumny do 1500znaków.
Czy rozdzielenie ich na nawet 4 oddzielne tabele jest lepszym rozwiązaniem i w żaden sposób nie powinno obciążać?

Drogi kolego, bazy danych SQL (pewnie używasz MySQL) są stworzone nie po to, aby stworzyć 2 czy 4 tabele, ale aby tworzyć ich tysiące (limit licz się w milionach tabel) i operować na gigabajtach danych (limit liczy się w terabajtach).

Także nie bój się dzielić - tylko dziel rozważnie, aby później na 50 rekordach nie robić 20 joinów (kilka joinów jest okay). ; )

Najlepiej byłoby, gdybyś przerobił choć jedną książeczkę o wybranej przez Ciebie bazie danych i wszystko stałoby się jasne.

Po prostu kiedyś słyszałem sugestie, że rozdzielenie danych na dwie tabele przy ich równoczesnym ładowaniu zwiększa prędkość ładowania, bynajmniej części danych. Czy teraz mogę myśleć, że to nie jest prawdą?

Oczywiście, że jak rozdzielisz to na 2 tabele w ten sposób co opisałeś to będzie wolniejsze. Wszystko zależy tak naprawdę do czego chcesz tego używać. Jakie zapytania do bazy będziesz robił, jak często i jak dużo insertów robił. Jeśli nie potrzebujesz po tych danych wyszukiwać to w ogóle można część danych wrzucić do json i zapisać do pola typu text. Każdy projekt jest inny i inaczej się projektuje bazę.

Pakowanie czegokolwiek do json, serialize itp. w MySQL jest totalnie bez sensu.
A co jak będzie chciał zmodyfikować jeden atrybut albo go wywalić. Nie musisz wtedy pobierać wszystkiego.

Ja rozdzielam dane w następujących wypadkach:

1. Gdy jeden zestaw danych może mieć wiele dodatkowych parametrów, np. klient może mieć przynajmniej 2 adresy do wysyłki
2. Gdy chcę pozakładać indeksy na różne zestawy danych i z testy wykażą, które rozwiązanie jest najkorzystniejsze
3. Gdy jakiś zestaw danych jest powtarzalny i można go potraktowac jako słownik, np miasta można upchać w select i wyszukiwać je w adresach po id, bo przeszukiwanie intów jest zawsze szybsze od przeszukiwania stringów.

Reasumując, tak jak koledzy napisali wszystko zależy od tego jakie dane chcesz upchać w tabelach, dlatego każdą bazę projektuje się "na miarę".

głównie tylko tekstowe (VARCHAR), natomiast INT wyłącznie dla może 3 kolumn (id, status...), czyli lepiej rozdzielić na dwie tabele w tym przypadku?