Als Ideenansätze kannst Du Dir ja mal die folgenden Links angucken:

ms-office-forum.net/forum/showthread.php?t=192186

ms-office-forum.net/forum/showthread.php?t=270263

Gruß

Rainer

Ich arbeite schon lange an einer Rezeptdatenbank, bin allerdings aus Zeit- und Lustmangel nicht besonders weit.
Ich werde allerdings „nur“ eine File-Datenbank wie SQlite nutzen, da mir ein Datenbankserver überdimensioniert erscheint.

Ideen kommen mir automatisch sehr viele, da ich selbst gerne koche, und weiß, was ich brauchen würde.

Ich hatte das schon mal recht weit fortgeschritten in Java, dann hatte ich das Mal in C# neu angefangen, und dann in VB.NET (hatte mehrere Gründe für dieses Chaos).

Für mich persönlich wäre eine Datenbank im Internet für eine solche Anwendung wie mit Kanonen auf Spatzen geschossen. Aber das ist nur meine persönliche Meinung. Wenn es dir so besser er-scheint, dann mach es so.
Der Nachteil ist dabei, dass Du immer Internetverbindung benötigst, und dadurch auch die Perfor-mance nicht ganz so gut ist. Lieber eine lokale DB nehmen, und ab und an sichern. Dann gibt es auch keinen Datenverlust.
Außerdem kann ich die Anwendung so auch an andere weiter geben, falls Interesse besteht.

Meine Ideen waren so im Groben:
- Rezeptkopf mit den Eckdaten + Rezeptpositionen mit den Zutaten
- Kategorisierung
- Lokalisierung
- Quellenangabe
- Wertung
- Foto
- Stammdatentabellen für so Zeugs wie Zutaten, Einheiten, Regionen, Kategorien, usw.
- Wochenplaner (wegen der wöchentlichen Frage „Was wollen wir diese Woche essen?“)
- Einkaufsplaner (resultierend aus dem Wochenplaner)
- Historie (wie oft und wann hat man was gegessen)
- Export/Import

Usw.
Für die Erste Version habe ich mir vorgenommen nur die Stammdaten und Rezepte inkl. Zutaten erfassen zu können. Der Rest folgt dann nach und nach.

Derzeit habe ich aber kaum Zeit und Lust dafür, da ich mich im Moment lieber mit Fotografie, als mit privater Programmierung beschäftige.

Lightsource schrieb:

Mir geht es hauptsächlich um Ideen für notwendige und sinnvolle
Funktionen die man einbauen sollte. Besser ich mache mir gleich
Gedanken über die Funktionen, dann muss ich später die Datenbank
nicht mehr verändern, falls sich das Daten-Konzept auswirken würde.

Das ist aber eigentlich der falsche Ansatzpunkt.

GUI-Funktionalitäten sind für ein Datenmodell eh vollkommen egal. Wenn das Datenmodell richtig aufgebaut ist, dann liefert es eh alles was Du jetzt oder irgendwann später an Daten benötigst.

Ein optimales Datenmodell das die Reaität perfekt abbildet ist was völlig anderes als ein Source-Code: Es wird sich nie ändern, es gibt einfach keine neuen Techniken oder bessere/optimalere Lösungen die sowas nötig machen würden.

Ein optimales Datenmodell kann man aber jederzeit gut erweiteren wenn zukünftig Anforderungen kommen die bei der Erstellung nicht bekannt waren und daher nicht berücksichtig wurden, aber auch hier erfolgt keine Änderung an dem bestehenden Datenmodell sondern nur Ergänzungen wie neue Tables oder Beziehungen und nur extrem selten mal ein neues Attribut.

Daher würde ich bei einer datenbank basierten Anwendung eh immer zu aller erst mit dem Datenmodell anfangen. Das ist ja eh (fast) völlig unabhängig davon für welches DBMS Du Dich dann letztendlich entscheidest.

Die Funktionalitäten ist in etwa so das letzte worüber man sich dann einen Kopf machen sollte. Natürlich stimmt das nur begrenzt, denn auch für die DB sind grundsätzliche Entscheidungen wie z.B. ob man eine Kostenermittlung (also was kosten die einzelnen Zutaten für ein Rezept und zwar runtergebrochen auf die genutzte Menge) mit einbauen will oder nicht. Aber das sind dann im Prinzip auch keine Funktionalitäts-Überlegungen sondern grundsätzliche Überlegungen zum Thema Leistungsumfang der Daten.

Gruß

Rainer

Sih dir mal diesen Threadh an:
[VB 2010] Ersatzteileverwaltung Tipps und sinnvolles Rangehen

Da kannst du viel über erm,s erfahren und auch der lernefeckt ist sehr groß

Lightsource schrieb:

Ja, danke, das ist wirklich schon mal hilfreich, raist10 erklärt das auch ziemlich gut.

Danke für das Lob.

Jetzt würde ich aber doch gerne wissen, wie man das mit den halben Eiern
abbilden könnte.
Nehmen wir mal an ich backe einen Kuchen in den 3 Eier gehören.
Will ich nächstes Mal nur die Hälfte backen, weil ich ein kleinere
Form ausprobieren will, dann müsste ich 1.5 Eier nehmen. Dann
nehme ich doch lieber gleich 2 Eier. Oder?
Aber das gilt ja vielleicht nur für Eier, bei anderen diskreten Zutaten
wäre es eventuell nicht sinnvoll. Beispielsweise die Verzierung.
Eine Torte hat immer eine bestimmte Anzahl Stücke. Auch wenn sie
insgesamt kleiner ist. Auf jedes Stück kommt nur eine Verzierung.

Gehe ich mit meinen Überlegungen schon zu weit?

Wenn Du den Thread den zn-gong gelinkt hat gelesen hast, dann wird Dir meine jetzige Antwort bekannt vorkommen:

Attribute interessieren an dieser Stelle erstmal genau Null. Wichtig ist erstmal das Du die Entitäten festlegst und die Beziehung der Entitäten zueinander bestimmst.

Erst wenn das alles stimmt kannst Du anfangen Dir über die Attribute einen Kopp zu machen.

Aber so prinzipiell würde ich das Thema "halbes Ei" wie folgt sehen:

Wenn Du 1.5 Eier brauchst für das Rezept dann gib das auch so in der Zutatenliste an. Macht ja kein Problem der DB beizubringen das sie hier auch Doubles akzeptieren soll. Dumm wäre es nur wenn du vor hast noch eine Bestandsverwaltung Deiner persönlichen Vorräte dahinter zu klemmen und die DB nun dazu bringen wolltest von Deinen 10 Eiern die verbrauchten 1.5 Eier abzuziehen um Dir als Bestand nach dem Backen noch 8.5 Eier anzuzeigen ... das wäre gar nicht sinnvoll.

Gruß

Rainer

Dabei wäre ein Attribut von Vorteil, welches anzeigt, wie viele Nachkommastellen möglich sind. Bei einem Ei wären das 0 Nachkommstellen. Wenn also 1,5 Eier bei der Berechnung rauskommen wür-den, dann müsste die Software runden.
Da dieser Wert aber nicht gespeichert wird, ist er erst mal für das Datenmodell unerheblich. Trotz-dem macht es Sinn die Menge der Zutaten als Fließkommazahl zu definieren, da es bei anderen Zutaten durchaus sinnvoll sein kann.

Lightsource schrieb:

Was meinst du mit nicht gespeichert?

Du würdest ja ein Rezept immer für eine bestimmte Anzahl Personen erfassen.
Ein Rezept wäre also von der Menge her für z.B. 4 Personen ausgelegt. Wenn Du dir das Rezept dann anzeigen lässt, und der Software sagst, dass Du aber nur für 2 Personen kochst, dann soll die Software die Mengen entsprechend umrechnen. Dieser umgerechnete Wert wird aber nicht gespeichert. Wozu auch.
Angenommen im Rezept steht, dass das Rezept für 4 Personen 3 Eier benötigt. Für zwei Personen wären das 1,5 Eier, was unter Umständen keinen Sinn macht. Du kannst aber ein Attribut bestimmen, bei dem Du sagst, dass die Mengeneingabe oder Ausgabe immer mit 0 Nachkommastellen erfolgen soll. Interne würde die Software weiter ihre Fließkomma-Mengen speichern und auch mit ihnen rechnen. Aber wenn sie 1,5 Eier errechnet, muss sie eben aufrunden, um auf Null Nachkommastellen zu kommen.
Eigentlich ganz einfach.

Lightsource schrieb:

Ich frage mich sowieso, ob Rezepte überhaupt abbildbar sind.

Warum nicht?
Dass es mehrere Variationen zu einem Rezept geben kann, ist klar. Daher gibt es auch öfters den Zusatz „… a la …“.
Entweder man legt pro Variation ein Rezept an, oder nur für die, die einen auch interessieren.
Außerdem würde man nur die Variationen erfassen, die sich stark vom „ursprünglichen“ Rezept unterscheiden.

Lightsource schrieb:

Ich glaube da hatten wir uns missverstanden.
Man wird kaum ein Ei halbieren, bloß weil bei der
Berechnung, die man macht, ein halbes Ei raus kommt.

Es gäbe also Zutaten, die hätten ein zusätzliches
Attribut, das aussagt, ob die Zutat teilbar ist,
ob sie abzählbar, oder wiegbar, oder ausliterbar
sei?

Nein, sondern die Mengen-Angaben bei den Zutaten bekommen die Möglichkeit Bruchmengen aufzunehmen. D.h. eben für Stückzahl-Angaben gibst Du dem DB-Field den DataTyp Float/Decimal und schon kannst du 1.5 Stück darstellen anstatt nur 1 oder 2.

Du musst Dir auf jeden Fall den Umgang mit den Mengen richtig überlegen ... Stück, Gramm, Kilogramm ^^, Liter, Milliliter, Centiliter etc., etc. ... .

Du brauchst dafür halt 2 Entitäten ... einmal die Entität Zutat und einmal die Entität Mengen. Die beiden werden dann mit einer m:n Beziehung verknüpft und über ein Zwischentable aufgelöst. In dem Zwischentable fügst Du noch dem Schlüsselpaar Zutat-Menge ein Zahlenfeld hinzu ... Decimal/Float mit zwei Nachkommastellen und darüber kannst Du dann alles abbilden:

Menge: Milliliter
Zutat: Milch
Zahlenwert: 500
RezeptID: 12345

Menge: Stück
Zutat: Eier
Zahlenwert: 1.5
RezeptID: 12345

Menge: Gramm
Zutat: Mehl
Zahlenwert: 250
RezeptID: 12345

Damit wären Zutat und Menge reine LookUp-Tables und werden erst durch die Verknüpfung und der Angabe des Zahlenwertes in Verbindung mit der RezeptID zu einer Zutatenangabe für ein spezielles Rezept.

Ich frage mich sowieso, ob Rezepte überhaupt abbildbar sind. Eine CD-Datenbank, oder ein anderes Lager
wird um einiges einfacher sein.

Nö, überhaupt nicht ... gerade nicht Läger wenn man Lagerbestandsverwaltung, Preishistorien etc., etc. mit einbauen will.

Das mag jetzt zwar tatsächlich nichts mit dem Datenmodell zu tun haben, aber es gibt für Käsekuchen bestimmt
100 versch. Rezepte. Am Schluss ist es vielleicht so, dass man Rezepte nur in einer Art Fuzzy-Logik
darstellen kann, weil es z.B. auch Übergänge von einem Rezept zu einem anderen gibt.
Das ist jetzt aber vielleicht zu philosophisch, obwohl es mich auch interessieren würde wie man so
eine Datenbank entwickeln könnte.

Und wenn es 1 Mio verschiedene Rezepte für einen Käsekuchen geben würde, ist das völlig latte weil jedes Rezept nämlich genau 1 mal in der Datenbank vorkommt ... nicht mehr und nicht weniger.

Es bringt Dir ja null zu sagen ab Stelle xyz sind die nächsten 3 Zeilen zwischen Rezept A und Rezept B gleich ... da es davor und/oder danach anders läuft sind die Rezepte unterschiedlich und stellen daher 2 völlig eigenständige Rezepte da.

Was Du machen kannst wäre aber Standard-Sachen zu führen und über eine rekursive m:n Beziehung Rezepte auch sich selbst abzubilden. Z.B. Hefeteig (wird ja immer gleich gemacht) wäre sowas ... anstatt bei jedem Rezept die Erstellung von Hefeteig zu schildern, erstellst Du ein eigenes Rezept für Hefeteig. Durch die rekursive m:n Beziehung Rezepte auf sich selbst kann Du jetzt jedem anderen Rezept das Rezept Hefeteig zuordnen und da m:n und nicht 1:n kannst Du so auch jedem Rezept mehrere dieser "Standard-Bausteine" zuordnen (z.B. wie schlägt man Eischaum oder sowas in der Richtung ^^).

Gruß

Rainer

Coole Idee - ist bisserl wie Links in Html.
Das würde auf eine "Sieheauch" - Entität hinauslaufen, die die Rezept-Entität mit sich selbst per m:n verknüppert?

ErfinderDesRades schrieb:

Coole Idee - ist bisserl wie Links in Html.
Das würde auf eine "Sieheauch" - Entität hinauslaufen, die die Rezept-Entität mit sich selbst per m:n verknüppert?

Ja, so in etwa kann man es sehen.

Man könnte dieses Vorgehen aber auch als multiple Vererbung sehen, Rezept X erbt die Informationen von Rezept Y und Rezept Z. *g*

Wenn man es als multiple Vererbung sieht, werden die Möglichkeit einer rekursiven m:n Beziehung vllt für den NET/OOP-gewöhnten-Programmierer deutlicher ... man erstellt Grundbausteine (Master-Class) und dazu dann unendlich viele Ergänzungs-Rezepte (Child-Class). Simples Beispiel wäre hier Pizza ... Master-Class ist die Erstellung des Teiges + Tomatensauce und dazu gibt es dann die Child-Classes Salami-Schinken-Käse, Ananas-Schinken-Käse, Hackfleisch-BBQ-Mozarelle etc., etc., etc. ... .

Gruß

Rainer

nein, Vererbung ist das nicht - das ist Composition.
X ist ein konkretes Objekt vom Typ Rezept.
Y ist auch ein konkretes Objekt vom Typ Rezept.

Vererbung kann sich aber nur zwischen Klassen (also Bauplänen) abspielen, nicht zwischen Objekten (Gebautem).
Eine Klasse RezeptDerivate könnte von Rezept erben, und wenn Y vom Typ RezeptDerivate wäre, hätte es alle Properties von Rezept, und dazu die Erweiterungen von RezeptDerivate.

Ist hier vollkommen unsinnig, denn X und Y sind Objekte derselben Klasse.

Die Composition besteht darin, dass X mehrere Verweise hat, auf annere Rezepte - zB auf Rezept Y.


Es wäre ganz unsinnig, für jedes Rezept eine eigene Klasse zu implementieren, also "unendlich viele" - und in einer Datenbank geht das schon gar nicht - das wären ja unendlich viele Entitäten.

@ ErfinderDesRades

Du siehst das ganze zu eng, bzw. nicht abstrakt genug.

Wir reden über ein ERM, ein ERM ist immer der Bauplan für die Daten. Und in dem Bauplan lege ich fest das Rezept von anderen Rezepten deren Eigenschaften erben kann und als eigenen Eigenschaften nach aussen hin ausgeben kann.

Wie ich gesagt habe, dass ist nur eine Sichtweise ... aber sie hilft es das Thema, bzw. die Möglichkeiten deutlich besser zu verstehen.

Vererbung in der Programmierung dient doch hauptsächlich dazu einen Grundbauplan zur Verfügung zu stellen und Code-Redunanzen zu vermeiden. Wenn nun jeder DS in einer DB von einem anderen eindeutig definierten DS "erben" kann, dienst das dem gleichen Zweck: man erbt immer denselben Grundbauplan an Informationen und vermeidet Daten-Rednunanzen.

Ja klar ... extrem abstrakt gesehen, aber Datenbanken muss man eben extrem abstrakt sehen um sie richtig zu verstehen. Trenn Dich einfach von Deiner Programmiererlogik (die ist bei Datenbanken tödlich) und von der normalen menschlichen Logik (auch die ist bei Datenbanken tödlich).

Veerbung in der Programmierung ist ja auch nicht das gleiche wie Veerbung im echten Leben und daher nur eine Abstraktion. Veerbung in Datenbanken ist auch nicht auf den Punkt genau das gleiche wie Vererbung in der Programmierung, aber es wird am Ende dasselbe erreicht ... Erbung eines Bauplanes und Vermeidung von Rednunanzen.

Und genau diese beiden Dinge sind für die Rezeptdatenbank und dem Thema rekursive m:n Beziehung optimal:

- man erbt immer den gleichen Informationsbauplan
- man vermeidet die gleiche Rezept-Basis mehrfach erstellen zu müssen und muss nur noch die Teile erfassen die sich dann unterscheiden

Geschickt in einem GUI eingebaut bekommt keine Sau mehr mit das es sich bei dem gerade vorliegenden Rezept um ein Rezept aus mehreren Rezepten handelt weil es wie aus einem Guß wirkt.

Okay ... aber denk hiermit dann genug der Philosophie zum Thema Datenbanken. Dürfte dem TE ja nicht wirklich so arg viel helfen, der braucht eher die konkreten Ansätze und dafür ist es völlig latte ob man die rekursive m:n Beziehung nun lieber als Composition oder doch eher als Vererbung betrachtet. Wichtig ist nur das es für ihn funzt und sein Problem löst. *g*

Gruß

Rainer

naja - aber du wolltest grade eine Nähe zum OOP-Denken herstellen

raist10 schrieb:

Wenn man es als multiple Vererbung sieht, werden die Möglichkeit einer rekursiven m:n Beziehung vllt für den NET/OOP-gewöhnten-Programmierer deutlicher

Vererbung ist nunmal ein grundlegendes Konzept von OOP, und ist ganz eindeutig definiert - ein fester Begriff (auch wenn nur wenigen die weitreichenden Auswirkungen und Möglichkeiten für die Programmierung klar sind).
Grade weil eiglich nurso wenige hier Lesende wirklich den Plan von Vererbung haben, wird denen ein Verständnis von OOP-Vererbung sehr erschwert, wenn der Begriff hier abweichend genutzt wird.

ErfinderDesRades schrieb:

naja - aber du wolltest grade eine Nähe zum OOP-Denken herstellen.

Okay ... damit hast Du Recht. Für mich ist es einfacher so zu denken/ zu überlegen und die Themen eben auf die grundlegenden Prinzipien runter zu brechen ... offensichtlich ist es das aber nicht für Alle.

Grade weil eiglich nurso wenige hier Lesende wirklich den Plan von Vererbung haben, wird denen ein Verständnis von OOP-Vererbung sehr erschwert, wenn der Begriff hier abweichend genutzt wird.

Ist ein Argument ... ohne Frage. Wobei ich aber davon ausgehe das es für den augenscheinlich sehr erfahrenen TE nicht zu trifft.

Gruß

Rainer