Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: jedna duza tabela czy kilka malych ?
Forum PHP.pl > Forum > Bazy danych > MySQL
zuraw84
witam,
chce stworzyc duzy sklep dla duzej ilosci uzytkownikow i zastanawiam sie
czy lepiej jest trzymac wszystkie produkty uzytkownikow w jednej tabeli
czy dla kazdego usera stworzyc inna tabele ?

czy znacie jakies stronki z testami wydajnosci bazy mysql questionmark.gif
nospor
A ile przewidujesz tych rekordow?
W kazdym bądź razie tworzenie oddzielnej tabeli dla kazdego usera nie jest dobrym pomyslem.
zuraw84
tego moze byc troche, dla kazdego usera bedzie z 10 tabel, userow od 10 do .... moze nawet 100 wiec jak
nazwe kazdej z nich rozpoczne od nr ID no to mysle ze nie powinno byc
burdelu, zreszta nie bede ich raczej chcial wszystkich razem ogladac
tylko te danego usera

a z kolei nie wiem jak mysql sie zachowa, czy latwiej mu bedzie (jak sadze, bo to raczej logiczne)
przeszukiwac tylko 1 konkretna tabele czy wszystko mu jedno i z duza tez sobie poradzi
TomASS
Moje zdanie jest takie:
Nie ma sensu trzymania takich samych danych (różniących się tylko jednym polem - ID_user) w różnych tabelach. Dodając nowego użytkownika będziesz tworzył specjalnie dodatkową tabelę? Kasując użytkownika będziesz kasował tabelę? MySQL na prawdę powinno sobie poradzić z dużą ilością danych, no chyba, że dane bedziesz miał liczone w dziesiątkach milijonów tongue.gif
SongoQ
Nawet jak bys mial kilka milionow w 1 tabeli to i tak to nie bedzie taki narzut czasowy, wszystko zalezy jak indexy zalozysz i jak umiejetnie zapiszesz zapytania.
bigZbig
Nie mowiac juz o tym ze jak stworzysz osobne tabele dla poszczegolnych uzytkownikow to wszelkiego rodzaju statystyki badz zestawienia produktow nie wedlug wlasciciela, ale wedlug np typu bedzi sie bardzo trudno robilo. O efektywnosci nie wspomne.
zuraw84
nie porownywac nie bede miedzy uzytkownikami,

a znacie moze jakies stronki z testami wydajnosci mysql questionmark.gif
TomASS
Cytat
nie porownywac nie bede miedzy uzytkownikami

Nigdy nie mów nigdy, może kiedyś będziesz musiał, tak jak mówi szanowny kolega bigZbig, robić statystyki na podstawie danych porozrzucanych po różnych tabelach. Nawet jeśli nie będziesz musiał tego robić i tak wygodniej jest trzymać podobne dane w jednej i tej samej tabeli.

Cytat
a znacie moze jakies stronki z testami wydajnosci mysql questionmark.gif

Google Twoim przyjacielem:
Google::test wydajności MySQL
wydajność MySQL
Google::performance MySQL
Skobi
Pomyśl jeszcze o jednej sprawie. Jak będziesz miał już tych 1000 użytkowników, a co za tym idzie 1000 tabel dotyczących tych użytkowników i będziesz musiał dodać jedną kolumnę do tabel użytkowników ( bo przecież z własnego doświadczenia kazdy programista powie, że nie da się wszystkiego przewidzieć ) to za bardzo nie widzę aktualizacji tych 1000 tabel. No oczywiście można napisać skrypt, który to za Ciebie wykona, ale jest to moim zdaniem fuszera i nie ma to nic wspólnego ze sztuką tworzenia relacyjnych baz danych.

I jeszcze jedna sprawa każde zapytanie w swojej aplikacji korzystające z tych tabel będziesz musiał poprzedzać prefixem Id uzytkownika, dla mnie osobiście to by było za bardzo upierdliwe.
zuraw84
Cytat(Skobi @ 2.08.2006, 14:47 ) *
I jeszcze jedna sprawa każde zapytanie w swojej aplikacji korzystające z tych tabel będziesz musiał poprzedzać prefixem Id uzytkownika, dla mnie osobiście to by było za bardzo upierdliwe.


no ok, bylo by troche upierdliwe ale bez przesady,


główny problem polega na tym, że przy każdym zapytaniu mysql musi przelecieć
całą tabelę, a tak (przy kilku) tylko jedną, małą ale skoro mówicie, że mysql powinien
sobie poradzić to ok ..... robimy na jednej .....
zobaczymy co z tego wyjdzie snitch.gif
SongoQ
Cytat
główny problem polega na tym, że przy każdym zapytaniu mysql musi przelecieć
całą tabelę, a tak (przy kilku) tylko jedną, małą ale skoro mówicie, że mysql powinien


Nie zawsze jest przeszukiwana cala tabela, wszystko zalezy od indeksow zapytan itd.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.