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.

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.

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ć.

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.

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



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ę

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 

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.

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