nicht angemeldet
Hello M. (bist Du's?),
Man sollte den Namen des Empfängers vom OWNER des Datensatzes trennen.
Das hab ich nicht ganz verstanden... Der Empfängername ist in meinem Fall immer der "usernick" des Empfängers [a-zA-Z0-9_], den ich als "global key" benutze.
kommt immer darauf an, wieviele Daten noch dranhängen und pb die ID nicht weniger Speicher kostet und ob der UserNick wirklich eineindeutig ist.
Gibt es denn vielleicht auch eine Dialog-Funktion, mit der festestellt wird, welche Kommunikation zwei Teilnehmer untereinander betrieben haben?
Ja. In meinem "Flatfile-System" mache ich das so, dass ich alle Nachrichten, die ein Benutzer schreibt oder empfängt, in "seine" .txt-Datei schreibe, inklusive Unix-Timestamp. Beim Auslesen brauche ich dann nur den Nickname des Kommunikationspartners zu "greppen" und die Zeilen nach dem Timestamp zu sortieren. Damit hab ich dann den kompletten Dialog zweier Teilnehmer chronologisch geordnet.
Ganz schön schlau, dafür die Unix-Funktionen zu benutzen. Die sind nämlich extrem schnell.
ID_msg bigint unsigned primary ID der Message
So eine ID brauch ich bei SQL wohl tatsächlich. In meinen Flatfiles benutze ich als msg-ID einfach den Timestamp, da es eher unwahrscheinlich ist, dass ein Nutzer 2 Nachrichten in der gleichen Sekunde bekommt.
Es ist besser, wenn man dedizierte Ändrungen (Löschen, Update) vornehmen will.
ID_OWNER bigint unsigned
ID_SENDER bigint unsigned
Das wären eher varchar(20)... ## bigint wäre dann nur 8Bytes lang, allerdings
## nenötigt man dann für die Abfage einen Join
MSG_DATE datetime
Mit Unix-Timestamps kann mySQL nicht umgehen, oder?
Doch, aber sie könnten bei 150 "gleichzeitigen" Prozessen nicht granular genug sein. Außerdem speichert MySQL die Timnestamps auch im Datetime-Format, was einen größeren Definitionsbereich bedeutet.
MSG_SUBJ char(40)
Gibt es nicht, kann also weggelassen werden. ## auf die 40 Bytes kommt es dann auch nicht mehr an
MSG_TEXT text Text der Meldung
MSG_READ tiny int Die Meldung ist schon geöffnet worden
MSG_REPLY tiny int Die Meldung wurde schon bearbeitet
MSG_DEL tiny int Delete-Flag um nicht bei jeder Löschung tatsächlich
löschen zu müssen. Da stirbt die Performance
MSG_OP_FLAG tiny int Merker für den Operator, wenn Meldungen z.B. ausgeblendet
werden müssen aber nicht gelöscht werden dürfenDie Flags sind natürlch wirklich eine gute Idee. Die hab ich bisher nicht benutzt, hört sich aber extrem sinnvoll an. Vor allem Danke für den Tipp, dass dauerndes löschen einzelner Einträge die Performance beeinträchtigt!
Das gibt geschäftze ca. 1.300 Bytes pro Datensatz
Das macht bei 100 Meldungen pro User, und 20.000 Usern ca. 2.6 GB
Damit ist MySQL 3.x für Deinen Anwendungsfall ungeeignet. Die Spezifikation von 4.x kenn ich noch nicht auswendig.Siehe http://dev.mysql.com/doc/mysql/en/Table_size.html
Sechster Kommentar von oben. Max size auf ext2 ist 2 TB.
Gut zu wissen...
Da wirst Du wohl entweder ein intelligenteres Flat-File Komzept bauen müssen, oder gleich auf z.B. Informix gehen müssen. Denn bei einem DBMS gleich in die Begrenzug zu fahren, ist ja nicht sehr sinnvoll.
Mein bisheriges Flatfile-System hat auch recht gut funktioniert. Nur müsste ich jetzt die User in Gruppen aufteilen und die Datenfiles dann in verschiedene Unterverzeichnisse. Warum werden denn DBMS dann so oft benutzt, statt einfach Flatfiles zu nehmen? Also, was in denn dann der große Vorteil von DBMS? Sorry, vielleicht ein blöde Frage, aber ich hab bisher immer nur Flatfiles benutzt und hatte nie große Probleme damit. Andererseits sieht man auch immer wieder, dass Leute für 20 Gästebucheinträge eine DBMS bemühen...
Kann man sich lange mit auseinandersetzen. Dennis Riehle und ich stricken da immer noch an einem Artikel, der garantiert 50 Seiten bekommen wird. http://forum.de.selfhtml.org/archiv/2004/5/82138/
Die erste Möglichkeite hat schon 119 Seiten Thread verursacht.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau