witam
bede mial stronke z bardzo duza baza danych(mysql) i teraz mam pytanie. Mam tabele uzytkownicy i w niej bedzie duzo kolumn jak haslo itp ale takze inne rzeczy jak poziom admina punkty premie itp. Czy lepiej jest podzielic taka duza tabele na oddzielne tabele typu:users,points,level czy uzyc jednej? Nie jestem pewien, w sumie gdy podziele na czesci bede musial zrobic wiecej operacji Select przy wyciaganiu bo zkilku bede wyciagal ale czy to bedzie szybciej gdy bede wyciagal powiedzmy po 3 informacje z 3 baz czy 9 z jednej? pozdro hell yeah
0
0
Na Twoje pytanie jest jedna odpowiedź: To zależy ;)
Jeśli miałbyś mieć taką tabelę:
Users
id
name
level (admin, user, guest)
points int
to lepiej level umieścić w osobnej tabeli tak jak napisałeś:
Users Levels
id id
name name
level_id (FK)
points int
Jeśli do tego potrzebujesz historię punktów:
Users Levels Points
id id datetime (pk)
name name user_id (pk)
level_id (FK) points
points int
I tak dalej. Generalnie jest tak, że im bardziej rozbijesz bazę tym lepiej. Nawet jeżeli od razu nie zauważysz zmiany jakościowej (a nawet stwierdzisz, że jest trudniej) to przy dalszym rozwoju aplikacji (a na 99% będzie dalszy rozwój) będzie Ci o niego łatwiej. Mnie nauczyło tego doświadczenie.
Z drugiej strony, jeżeli wiesz na 100% (ale serio na 100%, a nie na 99,(9)%), że nie będziesz potrzebował więcej leveli usera niż 2, to możesz dać jakiś set, albo enum. Jednak w takim przybadku powstaje sztywne powiązanie kodu z modelem danych (w kodzie zakładasz, że są trzy i dokładnie takie jak ...), które jest raczej nieporządane.
pzdr
0
juz bylo 100=99.(9) :d ,
ale popieram 100% musisz wiedziec, ze tak bedzie i nie bedziesz chcial tego zmieniac przynajmniej przez rok-dwa a najlepiej wcale.
0
odpowiedz jest taka - najpierw się baze normalizuje do 3 postaci a potem dopiero myśli, gdzie by tu można zdenormalizować aby osiągnąć większą wydajność
dsads napisał(a)
witam
bede mial stronke z bardzo duza baza danych(mysql)
duża to pojęcie względne - musisz chociasz rząd wielkości znać
Mam tabele uzytkownicy i w niej bedzie duzo kolumn jak haslo itp ale takze inne rzeczy jak poziom admina punkty premie itp.
"itp", "inne rzeczy" to dość nieprecyzyjne stwierdzenia.
Jak chcesz to daj pełną specyfikację co tam będzie a my Ci powiemy jak będzie szybciej
0
Dokładnie tak - najpierw zaprojektuj to w ten sposób, aby było znormalizowane i eleganckie, później baw się w optymalizacje. Rozbijanie wielokolumnowych tabel na kilka połączonych ze sobą jeden do jednego daje zwykle niewielkie zyski w porównaniu z tym co mozna osiągnąć np. indeksami, a często może zaszkodzić.
Jednak nie ma tu żadnych "złotych reguł", wszystko zależy od konkretnego przypadku.
Partycjonowanie poziome i pionowe zostaw sobie na koniec, jak indeksami nie wystarczy (nie wiem, czy MySQL w ogóle cokolwiek to wspiera). Ewentualnie rozważ lepszy RDBMS (PostgreSQL, MS SQL, Oracle, DB/2, Sybase ASA itp).