Jak w temacie, interesuje mnie jedno. Ile można maksymalnie dodać kolumn do tablicy w mysql? Interesuje mnie to, bo możliwe, że będę potrzebował około 100-150 =D. Jeśli taka ilość jest możliwa to też chciałbym wiedzieć czy taka ilość może jakoś wpłynąć na pracę strony. Zdaję sobie sprawę z tego, że może spowolnić lekko wczytywanie się strony, ale ja np chcę w tych tabelach umieszczać tylko i wyłącznie cyferki. Potrzebne mi to będzie po prostu do pewnych statystyk.

i cała reszta o tym:
http://dev.mysql.com/doc/refman/5.4/en/col...ount-limit.html

Generalnie jeśli będziesz miał jakieś problemy z MySQL, polecam dev.mysql.com, naprawdę bardzo dobrze opracowana dokumentacja, po php.net druga "najważniejsza" strona każdego developera PHP
//edit: oczywiście tego, który buduje serwisy w oparciu o MySQL, bo jeśli chodzi o Postgres'a czy Oracle'a, to będą to odpowiednio http://www.postgresql.org/docs/8.4/static/index.html oraz http://www.oracle.com/technology/documentation/index.html

Szczerze to nie wiem, ale to jest samobójstwo... Jeżeli Twój problem wymaga 100-150 pól w tabeli oznacza to tylko tyle, że źle do tego podchodzisz.

Napisz lepiej co potrzebujesz, na pewno da się to zrobić wydajnie i rozbić na kilka tabel tym samym przyspieszając pracę.

No więc wszystko się rozchodzi o mój klan. Grane są często po dwie mapy i to do nich chcę porobić różne staty. Na przykład ile razy była dana mapa grana(1 kolumna), ile razy na niej wygraliśmy(2 kolumna), remis(3 kolumna) i przegrane(4 kolumna). Teraz spojrzałem, że wszystkich map w soldacie jest 78 _^_ ... Teraz 78x4 no jakoś chyba nie bardzo to widzę, ale w ostateczności będę się z tym tak po lamersku męczył. Choć jak sobie pomyślę jak będzie wyglądało w skrypcie zapytanie INSERT INTO, albo SELECT FROM... Masakra. Też nie wszystkie te mapy są grane, nawet połowa z nich nie, ale jeszcze na dzień dzisiejszy nie potrafię zrobić by zliczało staty tylko z granych map.

[EDIT]
Zapomniałem dodać, że to są staty do graczy, ile razy kto i jak grał na tych mapach, nie do map, a do graczy.

A nie łaska rozbić to na dwie tabele?

Pierwsza:
id_mapy
nazwa_mapy
co_tam_jeszcze_potrzeba

Druga:
id_drugiej
id_mapy
grana_ile_razy
zwyciestwa
remisy
porazki

Bo jak Ci dojdzie kolejne 70 map to co, tak będziesz dziergał następne 280 kolumn w jednej tabeli?

gracze:

id, nazwa, i co tam potrzeba

mapy:
id, nazwa_mapy

staty:
id, gracz_id, id_mapy, wygrane, przegrane, remis

No właśnie tego będę chciał uniknąć za wszelką cenę, bo Soldat jest wciąż rozwijany i z każdą aktualizacją dochodzą nowe mapy.
I teraz jak tak patrze na wasze sugestie tabel to chyba będzie fajnie to tak rozbić na trzy jak fifi209 przedstawił.
Jeszcze jedno pytanie, czy tutaj to będą relację tabel? Tzn chodzi mi o klucze obce, bo właśnie ostatnimi dniami czytałem książkę"Ćwiczenia praktyczne SQL" Marcina Lisa i tam właśnie było coś bardzo podobnego.

Postaw na silniku InnoDB i zrób relacje. ;d To nic trudnego.

Nie chcę zakładać nowego wątku gdyż mój jest pochodny.
Opiszę problem poniżej:
Posiadam dwie tabele:
1) Trzyma dane użytkowników zarejstrowanych
2) Przetrzymuje części samochodowe które mogą się zepsuć(55 elementów).

Skrypt wykonuje się codziennie o wyznaczonej godzinie.

Obecne działanie skryptu:
1. Aktualizuje dane w bazie danych
2. Pobiera potrzebne dane z bazy.
3. Sprawdza warunki.
4. Jeżeli są spełnione to wysyła maila/smsa.

Cały problem polega na tym, że części samochodwe mają stałą wartość:
cześć 1: 80000km
części 2: 15000km
część 3: 50000km

Użytkwonik podczas rejstracji podaje wartość przebiegu auta np. 200000. Wartość przebiegu jego auta rośnie codziennie o np. 20km(średnio człowiek tyle robi w mieście codziennie).
O wyznaczonej godzinie skrypt się uruchomi i sprawdzi ze warunki są spełnione bo 200000>80000; 200000>15000; 200000>50000 i wyślę maila/smsa do użytkownika. Następnego dnia znów przebieg się zwiekszy i będzie 200020km i warunki są spełnione i wyślę tego maila smsa. A ja chcę żeby tego nie robił teraz(bo zakłądam że użytkownik wymienił te elementy) tylko zrobił to gdy przebieg osiągnie 280000 dla 1 części; 215000 dla 2 części i 250000 dla 3 części.
To jest jedna rzecz.

Kolejną rzeczą jest to, że trzeba jakoś zapamiętywać, że użytkownikowi się już dana część popsuła. Gdyż jeżeli Użytkownik nr 2 będzie mieć zepsutą część 1 to dostanie informacje o tym, że została popsuta i dodatkowo dostanie kontakt mailowy do użytkownika 1 w celu zwrócenia się o pomoc do niego.

Rozwiązanie "najbardziej toporne" to dodanie do tabeli użytkowników 55 kolejnych kolumn które będą przetrzymywać liczniki (ile razy element już był wymieniany). Następnie zwiekszanie tego licznika z każdym kolejnym spełnieniem warunku w skrypcie.
Zalety:
Mam informacje o tym jakie elementy już się zpesuły użytkownikowi.
Jestem w stanie bez problemu kojarzyć użytkowników z zepsutymi tymi samymi elementami.
Wady:
4-krotne powiększenie tabeli na przetrzymywanie tylko liczników.
Martwilem się, że tabela o ilości okolo 70 kolumn będzie zbyt duża, ale czytając ten wątek widzę, że jest ok.

Mogę również stworzyć 3 tabele samych liczników i połączyć ją z dwiema pozostałymi co wydaje się bardziej logiczne.

Macie może jakiś inny pomysł na zaprojektowanie tego skryptu w bardziej rozsądny sposób??

Z góry dziękuję za odpowiedzi.