"Einfache" Daten abspeichern, ohne gleich Nodes erstellen zu müssen?!

Vielleicht könnte man einen Nodetype dafür anlegen und jedem User nur einen einzelnen Node dieses Typs gestatten. Dann nimmt man für die Infos CCK-Felder mit der Anzahl "Unbegrenzt", dann könnte ein Benutzer ein Feld hinzufügen und die neuen Daten eingeben. Nicht ganz elegant und benutzerfreundlich, würde aber gehen.

Ich würde aber eher ein eigenes Modul schreiben, bei sowas kleinem ist das doch schnell erledigt. Install-Schema für die DB dauert nur ein paar Minuten, dann ein Formular mit den 3 Feldern dauert auch nur 20 Minuten, speichern der Daten dauert 5 bis 10 Minuten und die Ausgabe je nach Anforderung mal 30 Minuten bis 1 oder 2 Stunden, dann dürfte das Ding doch erledigt sein, oder?

Was stört dich an den Infos die Drupal zusätzlich zu den Nodes speichert? Ich finde die Variante mit den Nodes die sauberste Lösung. Damit kannst du dann auch ohne weiteren Zusatzaufwand alle in Drupal verfügbaren Funktionen nutzen.

Naja, bei den Nodes gibt es ja noch etliche weitere Einstellungen, die ja mit abgespeichert werden: Body-Feld kann man ja noch ausblenden, aber z.B. Auf Startseite anzeigen, Immer oben in Listen... dann die zusätzlichen Module in dem Projekt wie z.B. Eingabeformate, Content Profile, Menü-Einstellungen, Einstellungen für Kommentare... da wird doch sicherlich wenigstens immer in irgendeiner Tabelle eine "0" abgespeichert, wenn das auf den jeweiligen Node nicht angewendet wird, oder? Ich stelle mir das schon datenbanktechnisch nicht so gelungen vor, für drei Werte immer gleich noch eine ganze Menge weiterer, eigentlich unnötiger Daten abzuspeichern?!

OK, man kann diese Meinung durchaus vertreten. Ich finde halt man sollte nicht neue Datenmodelle in ein bestehendes einbetten. Wenn ich alle Anforderungen an ein Datensatz erfüllen kann, nehme ich lieber etwas mehr Ballast mit, als dan später festzustellen; "das hätte ich wohl doch auch mitnehmen sollen". Nun gut ich kann auch deine Position auch durchaus nachvollziehen.

Ich habe da ja keine Position, sondern eine Frage ;-) Und ich finde, dass das doch eigentlich keine Meinungs- oder Glaubenssache sein dürfte. Die Frage ist doch: Blähe ich die Datenbank mit unnötigem Ballast auf, wenn ich Nodes nutze? Und wenn ja: ist der unnötige Ballast so viel, dass es besser wäre, das über eine andere Lösung umzusetzen oder ist der zusätzliche Ballast zu vernachlässigen? Hat der zusätzliche Ballast überhaupt irgendeine Bewanntnis, sprich: Macht der das Projekt langsamer oder gibt es sonst irgendwelche Gründe, die dagegen sprechen könnten???

Also wenn Du wirklich nur 4 Werte (id, uid, datum, wert) wegspeichern willst und diese generell nicht unter node/% erreichbar sein müssen, würde ich dafür ein eigenes kleines Modul schreiben und die daten über die hooks an den user / die node anhängen oder wo auch immer sie dann verfügbar sein sollten.

Möchte das Thema gern nochmal aufgreifen.

Ich mache mir Gedanken darüber, ob es sinnvoll ist, mit Drupal-eigenen Mitteln zB Kundendaten zu speichern.

Ich sehe ein ähnliches Problem wie hier von tobi-berlin angesprochen. Die eigentlichen Daten werden mit bzw inmitten der ganzen anderen 'überschüssigen' Node-Daten gespeichert.

Drupal ist ja ein CONTENT Management System, aber trotzdem stellt sich mir die Frage, ob es nicht sinnvoller wäre, die Kundendaten in klar strukturierte eigene Tabellen abzulegen. Dann müsste man die Daten halt mehr 'von Hand' aus der DB holen bzw reinschreiben. Aber die Daten wären wohl im Fall der Fälle leichter zu exportieren zB für andere Anwendungen.

Was wäre sinnvoller?!?

Zum Thema Kundendaten:
Mir sind im Laufe der Zeit einige Kundendaten-Programme über den Weg gelaufen, alle handgebaut (also nicht Drupal), und bei
jedem ist früher oder später das Thema Versionierung aufs Tapet gekommen...
Bei Drupal wäre das ein Handgriff gewesen!

Drupal hat tatsächlich einigen Overhead für pimpflige Dinge, aber die haben das Potential zu wachsen.
Aus diesem Grund verzichte ich tendentiell auf eigene Tabellen und versuche das halt, Node-technisch zu lösen.

Ich mache mir schon längere Zeit Gedanken über das Thema, weil wir für unseren kleinen Familienbetrieb eine eigene einfache Lösung zur Verwaltung von Kundendaten und Arbeitsabläufen erstellen wollen.

So langsam freunde ich mich tatsächlich mit dem Gedanken an, die Drupal-eigene Datenverwaltung zu nutzen. (Meine Abneigung kommt wohl aus der Zeit, als ich vorwiegend Desktop-Anwendungen erstellt hab.)

Wahrscheinlich geht's eher darum, dass man es schafft, Drupal so 'natürlich' wie möglich zu nutzen, dh ohne irgendwas zurechtzubiegen und sich damit auf lange Sicht ins eigene Knie zu schießen.

Mal eine Frage an die Programmierer/ Erfahreneren: Wenn ich nun diese Daten per Views abfrage, dann werden doch auch tatsächlich nur die Tabellen zu dem jeweiligen CCK-Feld abgefragt, oder? Wenn ich eine Ansicht erstelle, wird nicht jedes Mal alles, was mit dem jeweiligen Node zusammenhängt, abgefragt, sondern nur die Daten aus dem Feld, das ich darstellen lasse, oder?

Sieh Dir doch die von Views erstellte Abfrage genauer an (sehe ich immer bei der Vorschau). Da wirst Du sehen, daß die nid aus der Node-Tabelle immer mit dabei ist. Bei dem Rest hängt es von den abgefragten Felden ab.

Beste Grüße
Werner

Du kannst Dir in Views immer den dazugehörigen SQL angucken. Normalerweise wird dieser SQL so gut wie möglich optimiert.
Ausserdem versucht auch mySQL selbst, möglichst effizient Daten zu holen.

edit: huh, werner war schneller :-)

Ach ja stimmt, man sieht ja die Abfrage. Bleibt dann aber eigentlich immer noch eine Frage: ist der entstehende datenmüll bei Nutzung der Nodes schlimm???? Ich habe mal gelesen, dass die Größe einer Datenbank keine entscheidende Größe ist, zum Beispiel im Hinblick auf Stabilität und Performance des Projekts. Stimmt das?

ein cck feld mit unbegrenzter feldanzahl ist glaube ich das einfachste