 Rejestracja i aktywacja użytkowników, a wydajność, dwa sposoby, który wydajniejszy? |
| Rejestracja i aktywacja użytkowników, a wydajność, dwa sposoby, który wydajniejszy? |
 
Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 30 Pomógł: 0 Dołączył: 12.01.2008 Skąd: Warszawa Ostrzeżenie: (0%) 
 |
Witam,
Otóż projektuję pewną aplikację sieciową w której umożliwiam użytkownikowi rejestrację. Po rejestracji konto trzeba aktywować itp. z technicznego punktu widzenia nie mam z tym najmniejszego problemu jednak dręczy mnie kwestia wydajności bazy danych. Zastanawiam się nad dwoma rozwiązaniami: rozwiązanie 1. Po rejestracji zapisuję dane użytkownika do tabeli tymczasowej gdzie czekają na aktywację linkiem z emaila, przy aktywacji dane są przenoszone do tabeli właściwej a te z tymczasowej kasowane, dodatkowo co 24h tabela tymczasowa jest opróżniana. rozwiązanie 2. Wszystkie dane (aktywne i nieaktywne) przechowywane są w jednej tabeli, podczas aktywacji wyszukiwany jest rekord i następnie aktywowany, co 24h cronem przeszukiwana jest cała tabela i czyszczona z nieaktywnych rekordów. rozwiązanie pierwsze wydaje mi się najlepsze, jedna moje wątpliwości budzi to, że podczas aktywacji trzeba wykonać dwa dosyć duże zapytania do bazy, rozwiązanie nr 2 wymaga tylko zmiany wartości jednego pola, jednak jeżeli baza będzie duża może być kłopot z wydajnością podczas wykonywania zapytania i przeszukiwania jej co 24h. Dręczy mnie to od kilku dni, pomoże ktoś? dzięki. Ten post edytował awakening 9.06.2009, 20:18:56 |
 |
 
|
 |
|
Post
#2
|
|
|
Grupa: Moderatorzy Postów: 15 467 Pomógł: 1451 Dołączył: 25.04.2005 Skąd: Szczebrzeszyn/Rzeszów |
Drugie rozwiązanie jest powszechnie stosowane.
Cytat jednak jeżeli baza będzie duża może być kłopot z wydajnością podczas wykonywania zapytania i przeszukiwania jej co 24h. Jeśli masz dobrze indeksy pozakładane, to nie ma problemu. |
|
|
|
|
Post
#3
|
|
|
Grupa: Moderatorzy Postów: 2 921 Pomógł: 269 Dołączył: 11.08.2005 Skąd: 127.0.0.1 |
1. Każda zmiana tabeli "głównej" będzie wymuszała modyfikację tabeli tymczasowej.
2. Zakładasz index na kolumnę, po której będziesz wyszukiwał i wydajność Ci nie padnie. |
|
|
|
|
Post
#4
|
|
|
Grupa: Zarejestrowani Postów: 30 Pomógł: 0 Dołączył: 12.01.2008 Skąd: Warszawa Ostrzeżenie: (0%)
|
to co piszecie wydaje się mieć sens (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) a co przemawia na niekorzyść rozwiązania pierwszego?
|
|
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%)
|
Cytat a co przemawia na niekorzyść rozwiązania pierwszego? Nie da żadnych sensownych korzyści, a jest bardziej czaso/zasobożerne
|
|
|
|
|
Post
#6
|
|
|
Grupa: Moderatorzy Postów: 2 921 Pomógł: 269 Dołączył: 11.08.2005 Skąd: 127.0.0.1 |
Cytat(batman @ 9.06.2009, 21:30:57 )  1. Każda zmiana tabeli "głównej" będzie wymuszała modyfikację tabeli tymczasowej. W zasadzie jest to największa wada, która na pewno da o sobie znać w najmniej oczekiwanym momencie.
|
|
|
|
 |
|
Aktualny czas: 2.10.2025 - 15:32 |
