27.07.2025, 15:51
Sprache ändern
Registrieren
Anmelden
Sie sind nicht angemeldet.
iNFiNiTE
God
[sql]: problem mit INSERT
Sonntag, 25. Mai 2008, 21:26
moin,
hab ein kleines problem..
wenn ich mittels
einen table erstelle kann ich nicht via
den aktuellen wert für die spalte "ergebniss" auf 1 setzen.
ich muss erst via
einmalig die 1 inserten und kann dann via UPDATE den wert ändern.
das problem ist aber dass ich neben "ergebniss" auch andere spalten habe und diese per script erstelle. wenn ich dann wieder INSERT aufrufe macht INSERT gleichzeitig auch eine neue reihe, was ich aber gar nicht möchte..
gibt es keine möglichkeit bei CREATE TABLE nicht direkt einen default wert reinzuschreiben? DEFAULT '1' bringt leider nichts.. ohne einen ersten INSERT hab ich keine erstelle reihe in der tabelle.
weiß jemand abhilfe?
messi
hab ein kleines problem..
wenn ich mittels
|
Quellcode |
1 |
CREATE TABLE IF NOT EXISTS player_Hans (ergebniss VARCHAR(11) DEFAULT '0') ENGINE = MYISAM |
|
|
Quellcode |
1 |
UPDATE player_Hans SET ergebniss = '1' |
ich muss erst via
|
|
Quellcode |
1 |
INSERT INTO player_hans (ergebniss) VALUES ('1')
|
das problem ist aber dass ich neben "ergebniss" auch andere spalten habe und diese per script erstelle. wenn ich dann wieder INSERT aufrufe macht INSERT gleichzeitig auch eine neue reihe, was ich aber gar nicht möchte..
gibt es keine möglichkeit bei CREATE TABLE nicht direkt einen default wert reinzuschreiben? DEFAULT '1' bringt leider nichts.. ohne einen ersten INSERT hab ich keine erstelle reihe in der tabelle.
weiß jemand abhilfe?
messi
iNFiNiTE
God
Re: [sql]: problem mit INSERT
Sonntag, 25. Mai 2008, 21:41
ich kann durchaus sql und kenne auch die grundlagen.. und ja, ich lege pro spieler eine tabelle an, das entspricht auch der normalisierung in meinem bsp.
in meinem fall brauch ich auch keine ID oder ähnliches..
es geht mir einfach darum, dass ich nicht möchte, dass INSERT mir eine weitere, neue zeile in die tabelle haut.
pro spieler sieht mein table in etwa so aus:
jedoch hat nicht jeder spieler zu jedem ergebnis einen eintrag. das bedeutet wiederum, dass wenn ich alle spieler in eine tabelle haue ich bei mehr als 70% der felder nur 0 als eintrag. daher pro spieler ein table.
messi
in meinem fall brauch ich auch keine ID oder ähnliches..
es geht mir einfach darum, dass ich nicht möchte, dass INSERT mir eine weitere, neue zeile in die tabelle haut.
pro spieler sieht mein table in etwa so aus:
Zitat
ergebnisA | ergebnisB | ergebnisC |ergebnisD |usw..
1 | 32 | 22 | 4 | usw..
jedoch hat nicht jeder spieler zu jedem ergebnis einen eintrag. das bedeutet wiederum, dass wenn ich alle spieler in eine tabelle haue ich bei mehr als 70% der felder nur 0 als eintrag. daher pro spieler ein table.
messi
Eikman
Moderator
Re: [sql]: problem mit INSERT
Sonntag, 25. Mai 2008, 22:14
da es sehr viele spieler gibt und ich nicht alle kenne (gleiches gilt übrigens für die ergebnisseX) mach ich das ganze dynamisch an.
Schon das ist ein Argument gegen dein Vorhaben.
Mein Vorschlag mit einer Spielertabelle und einer Tabelle mit Ergebnissen ist da deutlich praktischer. Du musst ja nur die Zeilen mit Ergebnissen != 0 in die Ergebnistabelle eintragen.
100.000 passt locker in jedes int und sonst gibt es bigint. Beides gibt es zusätlich natürlich als unsigned.
iNFiNiTE
God
Re: [sql]: problem mit INSERT
Sonntag, 25. Mai 2008, 22:17
bei meinem entwurf hab ich auch keine einzige zeile mit 0 , da ich ja pro spieler(tabelle) dynamisch spalten anmache, sobald der spieler bei einem bestimmten ergebnis ein resultat erzielt hat 
bigint hab ich auch schon probiert, wenn ich dann aber einen wert jenseits der 65536 eingebe bekomm ich in mysql nen error ???
so, meld mich in 2 std wieder, muss nun länder switchen
bigint hab ich auch schon probiert, wenn ich dann aber einen wert jenseits der 65536 eingebe bekomm ich in mysql nen error ???
so, meld mich in 2 std wieder, muss nun länder switchen
Y0Gi
God
Re: [sql]: problem mit INSERT
Sonntag, 25. Mai 2008, 22:27
ich hatte erst eine große tabelle in der alle spiele und alle spieler drinstehen, jedoch hab ich dann wie gesagt in 80% der felder ne 0.
Beides zusammen in *einer* Tabelle? Dann ist das wenig verwunderlich - aufsplitten.
und ja, ich würde am liebsten auch gerne ints einsetzen und keine varchars, jedoch hab ich leider auch ergebnisse die jenseits der 100.000 liegen und da scheint mysql nix passendes zu haben.
Hint: Der normale Integer wird in MySQL standardmäßig auf `INT(11)` gesetzt. 11, das ist die Zahl der Stellen. Von `BIGINT` gar nicht zu reden.
bei meinem entwurf hab ich auch keine einzige zeile mit 0 , da ich ja pro spieler(tabelle) dynamisch spalten anmache, sobald der spieler bei einem bestimmten ergebnis ein resultat erzielt hat
Fühl' dich dafür von mir auf'n Kopp gehauen
bigint hab ich auch schon probiert, wenn ich dann aber einen wert jenseits der 65536 eingebe bekomm ich in mysql nen error ???
Dann stimmt da bei dir was nicht. `BIGINT` geht von -9223372036854775808 bis 9223372036854775807.
Direkt zum Schema: Zwei Tabellen, `ergebnisse` und `spieler` (hier ist Englisch ein weiteres Mal besser: `players` trifft es durch das Mehrzahl-"s" genauer zur Abgrenzung eines einzelnen "Spieler"s). Beiden verpasst du direkt eine ID und setzt die als Primärschlüssel.
Je nachdem in welcher Beziehung die Ergebnisse zu den Spielern stehen, verwendest du eine entsprechende Relation und einen oder zwei Fremdschlüssel und ggf. eine Zwischentabelle. Betrifft bspw. ein Ergebnis nur einen einzigen Spieler, erhält die `ergebnisse`-Tabelle ein Attribut `player_id` als Fremdschlüssel.
Für jedes vorhandene Ergebnis machst du dann einen `INSERT` in die Tabelle. Ist der Spieler noch nicht angelegt, machst du vorher ein `INSERT` in die Spieler-Tabelle.
Eikman
Moderator
Re: [sql]: problem mit INSERT
Montag, 26. Mai 2008, 03:28
Übersichtlicher? Nur bis du auch andere Informationen in der Datenbank speichern willst.
Ausserdem geht dir vieles verloren:
- Keine schnelle Suche nach Spielern mehr
- Es ist komplizierter Abzufragen, ob es einen Spieler gibt
- Selbst das Erstellen einer Liste aller Spieler ist deutlich komplizierter
Allgemein ist alles was du mit den Daten machst um ein vielfaches langsamer, weil die Datenbank nicht optimieren kann. Nehmen wir mal an, du willst alle Spieler suchen, die ein Ergebnis > 100.000 haben. Du musst dir erstmal eine Liste aller Tabellen holen und dann in jede dieser Tabellen reinschauen. Vor allem bei großen Mengen an Spielern (von denen du ja sprichst), dauert das ewig und verursacht unnötig Rechenlast. Sogar umweltfreundlicher ist Yogis vorschlag, da der Rechner weniger Strom frisst
Ausserdem geht dir vieles verloren:
- Keine schnelle Suche nach Spielern mehr
- Es ist komplizierter Abzufragen, ob es einen Spieler gibt
- Selbst das Erstellen einer Liste aller Spieler ist deutlich komplizierter
Allgemein ist alles was du mit den Daten machst um ein vielfaches langsamer, weil die Datenbank nicht optimieren kann. Nehmen wir mal an, du willst alle Spieler suchen, die ein Ergebnis > 100.000 haben. Du musst dir erstmal eine Liste aller Tabellen holen und dann in jede dieser Tabellen reinschauen. Vor allem bei großen Mengen an Spielern (von denen du ja sprichst), dauert das ewig und verursacht unnötig Rechenlast. Sogar umweltfreundlicher ist Yogis vorschlag, da der Rechner weniger Strom frisst
