Warum baust du es nicht gleich auf Adaptern auf das man nicht an eine spezielle Datenbank gebunden ist?
\
Hab da derzeit keine Lust drauf, aber es nimmt ja dicts an, genau wie die CouchDB Driver daher kann man ohne weitere Probleme schnell nen Wrapper proggen, wenn benoetigt, da ich keinen solchen Wrapper kenne....
Xin hat geschrieben:Jside hat geschrieben:Eine Dokument basierende Datenbank, dort kann man direkt JSON Objekte reinschieben, diese muessen aber nicht gleich sein, daher wenn du z.b. Bildinformationen reinschiebst, aber keine Tags gegeben sind kannst du die Tags einfach auslassen, oder generell kannst du die Tags einfach in ein Array innerhalb des JSON Objektes reinschreiben und das wird dann so gespeichert(anstatt irgendwelchen ID verwaist auf andere Inhalte aus anderen Tabellen chaos wie bei SQL), alternativ gibt es auch CouchDB aber ich hab mich halt zur MongoDB entschlossen... MondoDB Teilt jedem "Dokument" automatisch eine ID zu(kann man aber auch selber uebernehmen).
Wie wird das ganze strukturiert?
Wie werden Referenzen verwaltet, wenn mehrere Objekte auf ein gemeinsames Objekt zeigen?
Garnicht entweder du schreibst alles in ein Objekt(was ja wiederum sub Obekte haben kann) oder du machts auf den SQL way(halt quasi ID verwaist auf andere ID). Sind uebrigends BSON nicht JSON objekte, CouchDB ist die von beiden mit JSON verwechsle ich immer... Das mit den IDs hatte ich ehr so in Form von du hast irgendwie ne Table mit id, key, value wo key ein Variablenname, Value - ist klar und id auf irgendein einen anderen Eintrag verwaist, und du dann quasi fuer irgendwelche Parameter sowas wie
SELECT * FROM properties WHERE id=7 veranstaltest, wie es anscheinend die MediaWiki derzeit macht:
http://www.mediawiki.org/wiki/Manual:Page_props_table und
http://www.mediawiki.org/wiki/Manual:Us ... ties_table was bei X Millionen Seiten und X Millionen usern bestimmt ganz witzig ist - zumindets nicht fuer den DB server... Bei Document NoSQL Datenbanken kannst du halt alles zum Objekt reinschieben z.b. ein Array mit subobjekten:
Kann natuerlich auch einen massiven overhead erzeugen wenn man dann die Querys nicht praezise auf das eingrenzt was man denn ueberhaupt auslesen moechte.
das Problem dabei ist aber noch, das - und ich hab mir die Sources von MongoDB nochnicht angeschaut - ich nicht glaube das MongoDB so schlau ist zu merken, das z.b. alle Artikel Objekte/Daten bei mir einen "Title" haben und diese Zeichenkette(also der Key Title) auf einen Pointer im RAM zu bringen oder so aehnlich zu speichern, was dann natuerlich gerade auch massiv HDD Speicherplatz brauche kann...
Xin hat geschrieben:Jside hat geschrieben:Das Python Interface von MongoDB nimmt Python dicts an, daher brauch ich nichtmahl die Membervariablen einzeln abzutippen (im Gegenteil ich hab eine zu entfernen - naemlich die ID) sondern kann einfach die __dict__ funktion nehmen, was sehr viele Vorteile hat. Abgesehen davon das wo SQL ehr dafuer gemacht ist auf einem (Gro[ss]))Rechner zu laufen die NoSQL Datenbanken ihre Staerke in Clustern haben.
Solange man nicht Wikipedia aufbaut, ist ein 10 Jahre alter Rechner ein Großrechner.
"Rechner" waren aber vor ca 20 Jahren Gro[ss]rechner, vor 10 Jahren waren Gro[ss]rechner Supercomputer zumindest in meiner Betrachtung...
Die Wiki Software benutzt ab jetzt Jinja2 als Template Engine, da mir die web.py mitgelieferte nicht gepasst hat, ansonsten koennte es sein, das die Software in 2 Tagen oder so zumindest mal anfaenglich benutzbar sein duerfte..
