[php+mysql] Budowa bazy Opcje

[Wykrywacz]

Mam takie pytanie koncepcyjne odnośnie budowy bazy (postaram się jasno).

Ma być to aplikacja do konwertowania kont bankowych.
User podaje plik, w którym są informacje (w jednej linii - każdy przelew).
Dalej leci konwersja.

Pliczek taki exploduje, i rozdzielone części wsadzam kolejno do bazy.
Z której potem interesujące mnie fragmenty poddaje różnym procesom.

Wszystko było by proste, dla jednego usera.

Problem w tym, że naraz może taką operację przeprowadzać 20 osób, więc nie może być to w jednej tablicy.

Myślałem, aby rozbijać to na użytkowników, gdzie każdy z nich pracowałby na własnej tablicy, a tym samym nie było by zagrożenia, że się dane pomieszają.

Lecz to nasuwa mi kolejny problem, jak kolejne paczki przelewów, numerować w tablicy tak, aby id przyznawało ten sam dla wszystkich rekordów w danej sesji a nie dla każdego rekordu osobna na zasadzie autoincrement.

Wogóle zastanawiam się czy ten typ konstrukcji wogóle jest prawidłowy. Co o tym sądzicie.

[cyphelf]

Zrób w tabeli pole user_id i przy wstawianiu wiersza dodawaj także numer identyfikujący użytkownika. Może to być numer użytkownika albo np. identyfiikator sesji.

[Wykrywacz]

No właśnie problem polega na tym, że nie wiem jak nadać autoincrementujący się id sesji a nie rekordu w bazie. (Wprowadzanie z ręki wogóle nie wchodzi w grę). id_usera, jest bez sensu, ponieważ każdy user będzie miał swoją tabele. (Swoją drogą id_usera też będzie ).

Tak, więc dla jasności problem : Jak zrobić autoincrementujący się id_sesji, nadający ten sam id całej sesji (od 1 do n - rekordów), a nie standartowo każdemu rekordowi kolejny numer id. Bądź czy ktoś z was ma pomysł jak można to inaczej rozwiązać.

Ten post edytował Wykrywacz 20.09.2006, 08:36:52

[SongoQ]

Nie wiem czy dobrze zrozumialem ale zapisujesz przelewy dla userow i chesz gdzies zapisac ze n przelewow przyszlo w jednej transakcji (transakcji zapisu przez Ciebie). Nie ma sensu rozdzielac na tabele dla kazdego usera. Numer transakcji moze to byc timestamp + wygenerowany numer od 0 - 1000 tak aby nie pojawily sie inne transakcje.

[dr_bonzo]

Tabela z sesjami, tam tworza ci sie autoinkrementujace ID i tyle, teraz uzywasz tego ID.

[Wykrywacz]

Tabela z sesjami, tam tworza ci sie autoinkrementujace ID i tyle, teraz uzywasz tego ID.

O i to wydaje mi się jest najlepsze rozwiązanie

Nie ma sensu rozdzielac na tabele dla kazdego usera.

W dalszej części, chce mieć łatwy dostęp do historii, tworzonych przelewów przez każdego użytkownika.
Dlatego chciałem zrobić osobną tabele dla każdego usera.
Ale masz rację, jeżeli dodam user_id, do tego pola to select, będzie banalny.
Tym bardziej, że nawet przy 30 naraz insertach mysql nie powinien mieć raczej problemów .

No chyba, że się mylę

[dr_bonzo]

Sytuacja jest prosta:
masz encje Uzytkownik, sesja, wpis (czy jak sie to tam zwie)

(Uzytkownik)-1-----*-( Sesja )-1----*-(wpis)

i tyle -- tworzysz nowa sesje, pobierasz jej ID i dodajesz wpisy z tym id.

Chcesz historie usera --

[SQL] pobierz, plaintext 
SELECT * FROM sesja WHERE user_id = $id
[SQL] pobierz, plaintext 

Chcesz wszystkie wpisy usera:

[SQL] pobierz, plaintext 
SELECT Uzytkownik.name, sesja.id, wpis.* FROM wpis, sesja, uzytkownik WHERE wpis.sesja_id = sesja.id AND sesja.user_id = user.id AND user.id = $x
[SQL] pobierz, plaintext 

[Wykrywacz]

OK dzięki. Z budową pytań sobie poradzę, chodziło mi w pytaniu raczej o efektywność aplikacji.
Ale zdążyłem sobie sam już na to pytanie odpowiedzieć

Jeszcze raz wielkie dzięki.

[SongoQ]

Jesli bedziesz robil operacje na tej babeli mowie tu o DML to warto zrobic tabele historii i triggerem kopiowac dane.