[mysql] tabela przechowujaca dane z rejestracji Opcje

[nobo]

Mam tabele w bazie danych, ktora przechowuje dane podane w procesie rejestracji (ID, login, haslo, imie, nazwisko ... )

Czy takie dane trzyma sie w jednej tabeli, czy lepiej rozbic na 2 tabele, z ktorych jedna bedzie posiadac pola login, haslo oraz ID ktory bedzie polaczeniem miedzy 2 tabelami, gdyz te dane beda czesciej wykorzystywane.

Czy czas sortowania 2 Tabel o tej samej ilosci rekordow, jest rozny w zaleznosci od tego z ilo pol sklada sie jeden rekord?


Nigdy nie projektowalem bazy danych, a zalezy mi na tym aby byla w miare optymalnie zrobiona.

Ten post edytował nobo 4.11.2007, 18:30:22

[rolnix]

Zależy, do czego będzie stosowana ta tabela. Rozbijaj tylko wówczas, jak masz zamiar trzymać tam sporo rekordów (parę tysięcy?). Z jednej strony ograniczysz liczbę zapytań, z drugiej czas pojedynczego zapytania - porównaj to do potrzeb i oceń.

[nobo]

Nastawiam sie na kilka tysiecy rekordow, dlatego myslalem aby rozbic na 2 tabele.


Mam jeszcze jedno pytanie dotyczace spraw optymalizacji bazy danych. A mianowicie:

Dane typu login czy adres email musza byc unikatowe, podczas rejestracji nastepuje proces sprawdzania czy takie dane nie wystepuja juz w bazie danych.
Przy kilku tysiacach rekordow, dane powinny byc posortowane aby mozna jak najszybciej wyszukiwac. (Mysle tu o algorytmach wyszukiwania dzialajacych na posortowanych zbiorach). Czy takie tabele sortuje sie podczas zapytania np. podczas rejestracji, w celu sprawdzenia czy np. login taki juz jest (co wydaje mi sie bardzo czasochlonne,) czy takie tabele sa sortowane na biezaco i ukladane hierarchicznie podczas dodawania nowych rekordow. Jak to jest w praktyce w bazach z bardzo duza iloscia rerkordow, gdzie czynnik czasu odgrywa najwieksze znaczenie.

Mialem do czynienia z programowaniem aplikacji, teraz rozpoczynam prace nad pewnym projektem (amatorskim ), gdzie optymalizacja bazy danych stoi na najwyzszym miejscu. A lepiej robic cos dokladnie od poczatku niz pozniej poprawiac.

[rolnix]

Nie ma sensu przez INSERT'em sprawdzać, czy login już istnieje - nadaj UNIQUE ID dla pól loginu i e-maila, po czym przechwycaj błędy przy dodawaniu. Skoro chcesz mieć te parę tysięcy userów, to któryś może się "wciąć" między sprawdzenie czy login istnieje, a jego dodaniem. Szansa jedna na milion, ale wtedy masz nieodwracalną kabałę

[nobo]

Dzieki za szybkie odpowiedzi. Duzo mi to pomoglo.

Czy w bazach z kilkoma/kilkudziesiecioma tysiacami rekordow wyszykuwiania odbywaja sie za pomoca zapytania SELECT czy trzeba wprowadzac jakies inne rozwiazania programowe w celu optymalizacji?

[rolnix]

SELECT

[PiXel2.0]

Ja tez robie podobny projekt i do sprawdzania czy login oraz e-mail juz sa w bazie uzylem takiej konstrukcji:

[SQL] pobierz, plaintext 
.
SELECT SUM(IF (user_name = 'UZYTKOWNIK', 1, 0) + IF (user_email = 'E_MAIL', 2, 0)) AS sprawdz_dane FROM uzytkownicy
.
[SQL] pobierz, plaintext 

Zapytanie zwraca mi pelny raport o tym co juz jest a czego nie ma.
wynik - znaczy
0 - nie ma nic
1 - jest login
2 - jest e-mail
3 - jest login i e-mail

Jak zwroci zero to dodaje rekord nowego uzytkownika insertem.

Ten post edytował PiXel2.0 5.11.2007, 00:36:08