sinnvolle Struktur für Termine verschiedenster Art

[Felix Riesterer]

Liebe Mitlesende,

ich habe Veranstaltungen die...

a) einmalig an einem Datum mit Uhrzeit an einem Ort
b) an mehreren Terminen (Termin = Set aus Datum, Uhrzeit und Ort)
c) regelmäßig monatlich an einem festen Wochentag wie z.B. 3. Mittwoch (+Uhrzeit +Ort)
d) regelmäßig monatlich an zwei oder mehr festen Wochentagen wie z.B. 2. Dienstag und 4. Freitag (+jeweils Uhrzeit +jeweils Ort)
e) regelmäßig wöchentlich an einem festen Wochentag (+Uhrzeit +Ort)
f) ausnahmsweise an Datum x von c)-e) abweichend an Uhrzeit+Ort

... stattfinden.

Auf der Suche nach einer geeigneten Tabellen- oder Datenbankstruktur bin ich noch nicht fündig geworden. Ich bin mir auch nicht sicher, ob das so einfach in einer einzigen Tabelle abzubilden ist.

Frage: Gibt es für soetwas nicht längst bewährte und ausgereifte DB-Strukturen, die zu finden ich nur noch nicht genügend geistreich gesucht habe, oder strickt da jeder immer wieder sein eigenes Süppchen?

Im Archiv bin ich über diesen Thread gestoplert, in dem Stammposter Auge iCalendar (RFC2445) erwähnt, das wohl _der_ Standard in diesen Dingen sein soll. Wäre das genau das, wonach ich suche? Wer kennt sich damit aus?

Liebe Grüße,

Felix Riesterer.

[CPAN]

Im Archiv [… RFC2445] erwähnt, das wohl _der_ Standard in diesen Dingen sein soll. Wäre das genau das, wonach ich suche?

Kurz und bündig: ja. Alles andere ist entweder ein neues Rad oder ein schlechter Hack, der den Anforderungen nicht genügt. Siehe auch: RFCs, die RFC2445 erwähnen.

Mit einer tabellarischen Datenbank wirst du allerdings nicht glücklich. Du brauchst Objektpersistenz wie z.B. durch KiokuDB.

[Felix Riesterer]

Liebe(r) CPAN,

[… RFC2445] Wäre das genau das, wonach ich suche?
Kurz und bündig: ja.
Mit einer tabellarischen Datenbank wirst du allerdings nicht glücklich. Du brauchst Objektpersistenz wie z.B. durch KiokuDB.

WTF!? Ich verstehe ja gerade einmal die Grundzüge einer Relationalen DB wie MySQL, nun aber eine davon völlig abweichende DB samt der zugehörigen API bzw. Abfragesprache zu erlernen sprengt meine Möglichkeiten im Moment bei Weitem.

Gibt es keine "abgespeckte" Lösung auf relationaler Ebene, die ich mit Hilfe meiner PHP-Scripte irgendwie einbinden oder nutzen kann? Immerhin soll das Ganze später auf einer XAMP-Lösung laufen. Gibt es dieses KiokuDB-Teil in ähnlichen Paketen wie XAMP eines ist?

Liebe Grüße,

Felix Riesterer.

[jobo]

Hallo Felix,

hier drei links als Ergebnis meiner unsystemantisch begleitenden Suche:

http://it-republik.de/php/news/MongoHQ-%2B-Zend-Framework--NoSQL-Webanwendung-054490.html
http://nosql-database.org/
http://www.lugv.at/node/43

Bitte keine Haue, wenns nicht passt.

icalendar ist doch nur ein austauschformat, also zuordnung von variablen und inhalten, oder?

Kann es sein, dass Du mit XML besser fährst? Damit kennst Du Dich doch gut aus.

Gruß

jobo

[dedlfix]

Hi!

WTF!? Ich verstehe ja gerade einmal die Grundzüge einer Relationalen DB wie MySQL, nun aber eine davon völlig abweichende DB samt der zugehörigen API bzw. Abfragesprache zu erlernen sprengt meine Möglichkeiten im Moment bei Weitem.

Üblicherweise sind die Schnittstellen zu NoSQL-Datenbanken recht einfach gehalten.

Gibt es keine "abgespeckte" Lösung auf relationaler Ebene, die ich mit Hilfe meiner PHP-Scripte irgendwie einbinden oder nutzen kann?

Klar, Serial LOB. Oder anders gesagt: Objekt serialisieren und als String speichern. Allerdings geht dabei auch die Funktionalität des Suchens drauf. Natürlich kannst du dir eine ((My)SQL-)Funktion schreiben, die deserialisiert und den gewünschten Vergleich vornimmt. Das läuft dann aber jedes Mal auf einen Full-Table-Scan mit Rückberechnung hinaus. Die Frage ist, ob eine NoSQL-Datenbank insgesamt Punkte bringt oder nur in diesem einen Teil-Aspekt. Üblicherweise funktionieren die so, dass man ein beliebiges Datenpakt ohne (feste) Struktur ablegen kann - beispielsweise als JSON-Darstellung eines Objekts. Für spezielle Selektionswünsche kann man sich dann eine Funktion z.B. in Javascript schreiben, die mit den Daten umzugehen weiß, und aufgrund von gezeilten Vergleichen mit Teilen des Datensatzes ein "passt oder nicht" berechnen kann.

Wie auch immer du dich entscheidest, die Komplexität der Serien-Termin-Möglichkeiten bleibt in beiden Systemen enthalten.

Lo!

[hotti]

Im Archiv [… RFC2445] erwähnt, das wohl _der_ Standard in diesen Dingen sein soll. Wäre das genau das, wonach ich suche?
Kurz und bündig: ja. Alles andere ist entweder ein neues Rad oder ein schlechter Hack, der den Anforderungen nicht genügt. Siehe auch: RFCs, die RFC2445 erwähnen.

Mit einer tabellarischen Datenbank wirst du allerdings nicht glücklich. Du brauchst Objektpersistenz wie z.B. durch KiokuDB.

Oder hotti's binary serialization ;-)

Das Rad neu erfinden? Ne, aber ich kanns vielleicht ein bischen beweglicher machen.

Viele Grüße,
Horst Schneckenwurst

[hotti]

moin,

Oder hotti's binary serialization ;-)

Das Rad neu erfinden? Ne, aber ich kanns vielleicht ein bischen beweglicher machen.

Nurmalso zur Info, mein Verfahren erhebt sich über sie 8 bit Grenze und erlaubt eine effiziente Speicherung und den Transport von Multipart Content für die hier genannte RFC. Desweiteren:

MIME
multipart/mixed

HTTP
multipart/form-data
application/x-www-form-urlencoded

JSON

Base64 ist damit überflüssig, es gibt keine Boundary mehr und auch keine hex-Dumps oder sonstige Delimiter. Der Speicherbedarf wird auf ein absolutes Minimum begrenzt. Das von einer Zeichenkodierung unabhängige Verfahren kommt in einigen meiner Anwendungen zum Einsatz, siehe auch Link und die Foren auf meiner Website.

Aufwachen ;-)

Hotti