Mitgliederverwaltung - Hilfe bei der Erstellung sauberen Codes

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 244 Antworten in diesem Thema. Der letzte Beitrag () ist von tragl.

    DerSmurf schrieb:

    Diese gibt es auch in deiner Version.
    Kunde.ScheinNr bleibt leer, wenn die Person keinen Fischereischein hat.


    Dann mach als Default-Wert "" in die Column, das ist als würde das was drin stehen (ein leerer String eben) und du kannst die trotzdem auf NotNull setzen. Bei mir in meinem riesigen DataSet gibt es keine einzige Column, wo DbNull erlaubt ist.

    DerSmurf schrieb:

    es soll abrufbar sein, wie viele Marken sich im Bestand befinden müssen

    DerSmurf schrieb:

    ein System zum Speichern der Abrechnungen / Lieferungen


    also ein kleines Warenwirtschaftssystem mit Bestandsführung ..

    Deine Abrechnung-Lieferung Tabelle ist falschrum. Du erzeugst so auch eine Ringrealtion mit Lieferant.
    Sinnvoller wäre hier die AbrechnungLieferung-Tabelle als untergeordnete von Artikel und Kunde (Person) zu machen.
    Denn über die ArtikelID kommst du auch an den Lieferanten dran.

    EDIT: Wenn du Hilfe beim Grundgerüst brauchst - schau' mal, dass du ein Headset fürn PC an den Start bringst, dann können wir
    am Wochenende spät abends auch gern mal ne Teamviewer/Teamspeak-Sitzung machen und das Grundgerüst zusammen bauen wenn du magst.
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:
    Jo, für Nullables sehe ich im Datenmodell auch keinen Bedarf.


    Anders als Tragl sieht mir die AbrechnungLieferung-Tabelle aber richtig aus.
    Zumindest als Lieferung-Tabelle sagt das Ding doch aus, welcher Lieferant an welchem Datum wieviele Marken einer Sorte geliefert hat - das ergibt doch Sinn.
    Könnte mir allerdings vorstellen, das ist noch zu simpel, weil bei einer Lieferung kann derselbe Lieferant vielleicht Marken verschiedener Sorten liefern - muss DerSmurf wissen, wie sich das verhält.


    Ähnlich kann sich das mit den Verkäufen verhalten: Wenn Kunden bei einem Einkauf überwiegend mehrere Marken verschiedener Art kaufen, dann braucht man eine Tabelle Einkauf, und was derzeit VerkaufteMarke heisst, wäre in "EinkaufPosten" umzubenennen.
    Oder so ähnlich.


    Warum die Lieferung-Tabelle gleichzeitig auch Abrechnung heissen soll versteh ich nicht.
    Als Abrechnung täte ich etwas erwarten, was aussagt: "In dem und dem Zeitraum hab ich hiervon 30 Stück verkauft, davon 25, und von XY bin ich keine losgeworden."


    Achja: Ich würde die Benamung nicht englifizieren. Oder willst du es an Engländer verkaufen, bzw. mit Engländern zusammenarbeiten? Oder es einer englisch-sprachigen Community zur Verfügung stellen?
    Das wichtigste ist doch, dass die das Programm erstellen oder warten, es verstehen.
    Von daher ist verständliche, selbsterklärende, kurze Benamung ganz ganz ganz entscheidend.
    Und ist auch in vielen Fällen schwierig, den richtigen Namen zu finden, der wirklich präzise aussagt, was die Tabelle bzw. Spalte darstellt.
    Das ist für einen Deutschen auf deutsch schon eine enorme Anforderung - natürlich auf Englisch nur noch schwieriger, und daher im Ergebnis auch schlechter.
    Weil auf Englisch werden a) sicherlich weniger treffende Bezeichner gefunden, und b) wer das liest muss Englisch dann ja auch so gut beherrschen, dasser die Bezeichner denn auch richtig versteht.
    Also Englifizierung hat nur Nachteile, aber keinen Vorteil.

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „ErfinderDesRades“ ()

    ErfinderDesRades schrieb:

    Also Englifizierung hat nur Nachteile, aber keinen Vorteil.

    und genau da tu' ich mich im Code selbst schwierig. Das ist inzwischen eher ein Denglisch geworden- weil man ist "gewohnt" in der Computersprache alles auf Englisch zu machen bzw. zu lesen, aber mein Programm z.B.
    wird auch nie in's Ausland gehen - folglich würde deutsch reichen....

    Aber bei den Tabellen würd ich's auch auf deutsch belassen.
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    ErfinderDesRades schrieb:

    Also Englifizierung hat nur Nachteile, aber keinen Vorteil.
    So ketzerisch kann ich das nicht unkommentiert stehen lassen.
    Ich arbeite seit Jahrzehnten in internationalen Umgebungen und bin sehr froh, dass ich von Anfang an dazu erzogen wurde, englisch zu codieren.

    Kürzlich hatte ich ein "spanglisches" Programm eines spanischen Kollegen in den Fingern und da wurde mir wieder richtig bewusst, wie wichtig es für die Lesbarkeit ist, dass der Code nicht "obfuskiert" ist.
    Die Syntax der gängigen Programmiersprachen ist englisch. Sowieso bei VB und .NET.
    Der Code liest sich sehr viel flüssiger, wenn sich keine Fragmente anderer Sprachen darin verbirgt (selbst wenn man die verwendete Sprache versteht).
    Das gilt auch für SQL, auch wenn ich da in rein nationalen Datenbanken Ausnahmen akzeptieren würde, wenn die zugehörigen Fachausdrücke nur schwer übersetzbar sind.

    Jeder Programmierer weltweit hat in der Schule Englisch gelernt.
    Lass ihn das nutzen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    petaod schrieb:

    Ich arbeite seit Jahrzehnten in internationalen Umgebungen...
    Das ist was anderes als hier der Fall.
    Natürlich muss man in internationalen Zusammenhängen sich einer "Amtssprache" bedienen, und weil Esperanto sich nicht durchsetzen konnte muss man mit Englisch vorliebnehmen.

    petaod schrieb:


    Jeder Programmierer weltweit hat in der Schule Englisch gelernt.
    Lass ihn das nutzen.
    Schul-Englisch reicht nicht, um die oft hochspezialisierten Sachverhalte präzise und unmissverständlich zu formulieren.
    "AngelVerein", "VerkaufteMarke", "FischereiNummer", "Angelschein", "NeuAnmeldung", Einkauf, Lieferung, Abrechnung, Einnahme, Ausgabe, Verzug, Aufschlag, ... - alles Worte, dich ich in Englisch nicht sicher auszudrücken wüsste.
    Und wenn der Coder zum Schreiben, und dann nochmal der Leser zum Lesen ein Wörterbuch braucht (und dann immer noch nicht sicher sein kann, denn viele Worte haben mehrere Bedeutungen) - das ist imo ein deutlicher Abstrich anne Wartbarkeit.
    Tatsächlich ist mir die Sprache sogar egal. Woraufs ankommt ist, dass eindeutig, kurz und leicht verständlich ist, was gemeint ist.
    Viele Begriffe sind mir auf englisch geläufiger, dann nehme ich englisch: Account, Login, Branch, User, Get, Set, Put,...

    ErfinderDesRades schrieb:

    Viele Begriffe sind mir auf englisch geläufiger,


    jupp, so mach ich das auch. Es gibt auch Begriffe die im englischen um ein vielfaches kürzer sind, da nehm ich dann auch Englisch anstatt Deutsch...
    aber ich glaub zu dem thema gibt's zuviele Meinungen, um das auszudiskutieren ;)
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    petaod schrieb:

    Kürzlich hatte ich ein "spanglisches" Programm eines spanischen Kollegen in den Fingern und da wurde mir wieder richtig bewusst, wie wichtig es für die Lesbarkeit ist, dass der Code nicht "obfuskiert" ist.

    Damit hast du Recht. Und es wird natürlich im Code nachher nur Englisch geben (Variablenbennung, usw.), aber ich finde @ErfinderDesRades hat hier schon recht.
    Ich durfte bereits lernen, dass es beim DataSet essentiell wichtig ist, dass sofort genau klar ist, was eine TableRow speichert.
    Das ist wohl in den meisten Fällen in Englisch problemlos machbar (und dann sinnvoller), aber in diesem Fall ist die Deutsche Bezeichnung (zumindest für uns Deutsche) wohl wesentlich aussagekräftiger.
    Natürlich kann ein Ausländer dann nur schwer was mit dem Programm tun (aber diese hätten auch wenig Verwendung dafür - weil unser Fischereigesetzt in DE ist schon was besonderes...

    tragl schrieb:

    Dann mach als Default-Wert "" in die Column

    Ah. Das bewahrt mich dann vor diesen permanenten ​If not TableName.IsRowNameNull Abfragen. :)
    Habe ich im DB Designer geändert. Die Boolean nullabalse habe ich dann auf False gesetzt.

    ErfinderDesRades schrieb:

    Könnte mir allerdings vorstellen, das ist noch zu simpel, weil bei einer Lieferung kann derselbe Lieferant vielleicht Marken verschiedener Sorten liefern - muss DerSmurf wissen, wie sich das verhält.

    das kommt vor. DER Verein liefert z.B. DAV Erwachsen UND DAV Jugend
    da geh ich nochma ran.

    ErfinderDesRades schrieb:

    Ähnlich kann sich das mit den Verkäufen verhalten: Wenn Kunden bei einem Einkauf überwiegend mehrere Marken verschiedener Art kaufen, dann braucht man eine Tabelle Einkauf, und was derzeit VerkaufteMarke heisst, wäre in "EinkaufPosten" umzubenennen.
    Oder so ähnlich.

    Das verstehe ich nicht. Ein Kunde kauft NIE mehrere GLEICHE Marken zur gleichen Zeit. Wenn mehrere (was oft vorkommt), dann immer verschiedene. Also 1x DAV und 1x Fischereiabgabe ist die Regel. Aber das ist in meinem DataSet doch abbildbar (mit 2 verkaufte Marken Rows).

    ErfinderDesRades schrieb:

    Warum die Lieferung-Tabelle gleichzeitig auch Abrechnung heissen soll versteh ich nicht.

    Ich verstehe unter Lieferung: Der Verein bringt 100 Jahreskarten
    unter Abrechnung: Der Verein bekommt Geld für 30 Jahreskarten
    Da ja nur bezahlt wird, was auch verkauft wurde, dachte ich mir es ist so ähnlich wie eine Lieferung und passt in eine Table.
    Alles was nicht verkauft wurde (am Jahresende), geht zurück an die entsprechende Stelle, ohne das hierfür Geld geflossen ist.
    Verstehst du was ich will / meine?

    ErfinderDesRades schrieb:

    Achja: Ich würde die Benamung nicht englifizieren.

    Dem stimme ich zu.

    DerSmurf schrieb:

    Ich verstehe unter Lieferung: Der Verein bringt 100 Jahreskarten
    unter Abrechnung: Der Verein bekommt Geld für 30 Jahreskarten
    Da ja nur bezahlt wird, was auch verkauft wurde, dachte ich mir es ist so ähnlich wie eine Lieferung und passt in eine Table.
    Ah - das Kommissions-Geschäfts-modell!

    Hab ich aber nachwievor spontane Zweifel, ob man Abrechnung und Lieferung als dieselbe Art Vorgang in eine Tabelle stopfen kann.
    Bei einer Lieferung fliesst kein Geld, bei einer Abrechnung schon.
    Aber vielleicht ists ja tatsächlich ein Vorgang, also der Lieferant nimmt auch gleichzeitig das Geld der bis dahin verkauften Artikel in Empfang.
    Werden unverkaufte Artikel eiglich auch zurückgenommen?
    Ah. Jetzt hab ichs
    Lieferung und Abrechnung sind zwei Vorgänge!
    Also auch, wenn ich Marken bekomme und dabei verkaufte Marken abgerechnet werden, handelt es sich um zwei Vorgänge.
    Diese wollte ich dann in zwei separaten Rows in der Abrechnung / Lieferung Table speichern (weil ich ja die gleichen Dinge speichere | Datum, Lieferant, welche Marke(n), wie viele, Gesamtsumme). Das ist ja gleich bei einer Lieferung, wie bei einer Abrechnung.
    Aber ich sollte dann wohl noch eine boolean einfügen (IstLieferung), um Abrechnung, von Lieferung zu unterscheiden.
    Kann das dann so bleiben, oder wäre es besser zwei Tables zu erstellen?

    Ich verstehe nur nicht, wie ich bei einer Lieferung / Abrechnung mehrere Marken verwalten kann.
    Jetzt verweist die Abrechnung / Lieferung Table auf die MarkenID. Also geht ja nur eine.
    Also in einem Lieferungsvorgang zwei verschiedene Marken vom gleichen Lieferanten.


    Kannste dir so ähnlich vorstellen, wie wenn du alle deine Einkaufszettel sammelst:
    Da kommen viele Läden vor, in jedem Laden käufst du mehrmals ein, pro Einkauf Artikel verschiedener Art (hier: Marke).
    Auf jedem KassenBon sind Bon-Positionen gelistet - je eine ArtikelArt, unter Angabe der Anzahl



    Ich gebe dir im übrigen inzwischen recht - scheint mir nun auch möglich, Lieferung und Abrechnung in derselben Tabelle zu führen, und einfach anhand eines Bools IsAbrechnung zu unterscheiden.
    Bei IsAbrechnung muss man die Anzahlen vom Bestand subtrahieren, und ausserdem die Marken-Preise zusammenrechnen und auszahlen.
    Oder vlt. noch einfacher, sogar ohne IsAbrechnung: Eine Abrechnung hat einfach negative Anzahlen.
    Dann ergibt sich der Bestand einfach durch Aufsummieren aller Anzahlen.
    Aber dennoch ist da inne Verarbeitung eine Unterscheidung zu treffen, weil bei "negativen Lieferungen" musst du Geld ausgeben, bei positiven Lieferungen bekommst du aber keines.
    Sondern Geld bekommst du durch die Verkäufe - und das ist nu aber doch eine andere Tabelle.

    (oder meinst du, die kriegen wir da auch noch reingebastelt?
    Naja, denkbar ist das: Ein Kunde ist ein Lieferant, der nur negativ liefert (er nimmt ja was mit), und bei dem du für die negativen Lieferungen geld bekommst.
    (Aber mir wird das zu wuschig...))

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Deine Datenstruktur oben verstehe ich nur halb. Da muss ich morgen erstmal ein bisschen rumprobieren und deinen Post noch ein paar Mal lesen, dann wird das schon.

    Zum anderen habe ich noch eine Frage.
    Spielt es für das Programm eine Rolle, ob es eine Tabelle für Lieferung und Abrechnung zusammen gibt, oder ob beide eine eigene Tabelle haben?
    Theoretisch müsste doch der Speicherbedarf (und damit die Ausführungszeit) ziemlich gleich sein. So würde ja meine Herangehensweise (beide in einer Tabelle zu speichern, um eben eine Tabelle einzusparen), auf einem Denkfehler im Ansatz beruhen.
    Dann stellt sich die Frage, ob es nicht für das Schreiben des Codes einfacher wäre mit einer Lieferungstabelle und einer Abrechnungstabelle zu arbeiten.
    Es könnte z.b. Einfacher sein, wenn ich später eine Übersicht einbauen möchte, wie viele Marken ich wann bekommen habe. Ich würde mir z.b. das filtern nach "istAbrechnung" bzw. Nach istMenge > 0 sparen.

    Edit:
    Ich halte allerdings das mit dem Geld nicht für so wichtig.
    Die Spalte Gesamtsumme in der Lieferung Abrechnung Tabelle habe ich nur integriert, weil ja zu einer Abrechnung irgendwie eine Summe gehört.
    Generell kann ich ja aber anhand der verkauften Marken abzgl. Der Menge an abgerechneten Marken jederzeit errechnen, wir viele Moneten ich haben muss. Den generell hantiere ich ja hier mit Geld (für so einen Verein viel Geld) dass mir nicht gehört. Da macht es sicherlich Sinn eine Kontrollfunktion zu haben, ob die Summe die hier rumliegt korrekt ist.
    Aber ich glaube den Punkt Geld können wir im DataSet weitestgehend ignorieren.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „DerSmurf“ ()

    DerSmurf schrieb:

    Aber ich glaube den Punkt Geld können wir im DataSet weitestgehend ignorieren.

    Dann mach's doch direkt richtig und hast eine Art Kassenprogramm mit integriert. Dann kannste dir mit ein paar Klicks alles rausziehen, was der Verein denn dann wissen möchte. Sprich:
    Du hast alles an zentraler Stelle und nicht in 2,3,4 oder Drölf Programmen.
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:
    Hmm. Der Verein will eigentlich nix wissen, außer 30 Marken verkauft, ich komme 2000 Euro einsammeln.

    Also es muss nicht gespeichert werden, dass Jan der Angler 120€ bezahlt hat.
    Es interessiert eigentlich nur, welche Marken er wann gekauft hat.
    Da die Geschichte ein non Profit Ding ist, gibt es nicht die Standart Elemente einer normalen "IchKaufeWareImGroßhandelUmDamitGeldZuVerdienen" Geschichte.
    Geld ist hier nur eine Nebensache.
    Die Kontrolle, ob die Summe die ich habe korrekt ist und eine Anzeige was ein Kunde beim Kauf von x Marken zu bezahlen hat (damit ich keinen Taschenrechner brauche) mehr tut nicht Not.

    Edit: ich mache morgen Mal einen Screenshot von meinem aktuellen Excelsheet (Summenkontrolle) Dort wird ersichtlich, dass die Implementierung eines Kassenprogrammes in die falsche Richtung geht.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „DerSmurf“ ()

    DerSmurf schrieb:

    Theoretisch müsste doch der Speicherbedarf (und damit die Ausführungszeit) ziemlich gleich sein...
    Speicherbedarf, Ausführungszeit sind völlig irrelevant - daran solltest du keinen Gedanken verschwenden.
    Ob das Proggi nun 0,1% deines Speichers belegt - den es beim Schliessen ja eh wieder freigibt - oder mw. das zehnfache: 1%. Beides quasi unendlich irrelevant, und 10 * unendlich ist bekanntlich auch nur unendlich.
    Ebenso die Geschwindigkeit - Ob die Abrechnung in 0,1 Millisekunde erfolgt oder in 1 ms - niemand kann das wahrnehmen.
    Unendlich viel wichtiger ist die Wartbarkeit deines Proggis, also: Lesbarkeit, Verstehbarkeit, Verbesserungsfähigkeit bei geringstmöglichem Risiko, Bugs einzubauen, sowie Leichtigkeit, Bugs zu fixen.
    Weil Bugs sind wahrnehmbar.
    Daher: Über Speicherbedarf, Ausführungszeit auch nur zu denken ist verboten, weil kann nix nützliches bei rauskommen, wohl aber unnützliches.

    DerSmurf schrieb:

    Spielt es für das Programm eine Rolle, ob es eine Tabelle für Lieferung und Abrechnung zusammen gibt, oder ob beide eine eigene Tabelle haben?
    Das wichtigste ist, dass das Konzept stimmig ist.
    Oft gibt es eine klar auffindbare beste Lösung - welche auch noch frühzeitig als solche erkennbar ist.
    Oft genug aber auch sind mehrere Wege möglich, bei denen man kaum bestimmen kann, welcher besser ist - zumindest nicht in Vorraussicht.

    Hier konkret kann ich mir 3 Ansätze vorstellen:
    1. Lieferung, Abrechnung, Einkauf sind getrennte Entitäten/Tabellen
    2. Lieferung + Abrechnung kann man als dasselbe modellieren
    3. Alle drei: Lieferung, Abrechnung, Einkauf - kann man als dasselbe modellieren
    1. ist wohl die klassische Sichtweise, 2. entstand bei näherer Betrachtung deiner spezifischen Geschäftsvorfälle, 3. findich originell, nahezu experimentell.

    Wie ist das eiglich inne Relität, bei einer "Lieferung": Erfolgt im selben Zuge auch eine Abrechnung?
    Also reichst du das eingenommene Geld der verkauften Marken weiter, und bekommst im selben Zuge auch gleich neue Marken in Kommission geliefert?

    DerSmurf schrieb:

    ob die Summe die ich habe korrekt ist und eine Anzeige was ein Kunde beim Kauf von x Marken zu bezahlen hat (damit ich keinen Taschenrechner brauche)

    also doch Geld im DataSet :P Naja, mach erstma Grundgerüst und deine Gedanken zum Post vom ErfinderDesRades - das mit dem Geld könnte man auch noch nachträglich einbauen. Vielleicht fällt dir beim Testen auf, dass du es wirklich nicht brauchst oder dir fällt vielleicht
    auf, dass du es sogar unbedingt brauchst weil es dir das Leben leichter macht. War nur so ein Anstoss ob man das nicht direkt von Anfang an mit einbaut.

    Besser haben und nicht brauchen als brauchen und nicht haben. ;)
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:
    Ich wollte eigentlich heute Vormittag das DataSet zusammenklicken. Aber ich komme nicht dazu (zuviel zu tun).
    Werde ich heute Abend erledigen.
    Deine Frage wollte ich nur schnell beantworten.

    ErfinderDesRades schrieb:


    Wie ist das eiglich inne Relität, bei einer "Lieferung": Erfolgt im selben Zuge auch eine Abrechnung?

    Nein. Nicht immer. Z.B. bei erster Lieferung, gibt es ja nix abzurechnen, und bei der letzten Abrechnung eines Jahres, gibt es noch keine neuen Marken für das nächste Jahr (1. Lieferung meistens im Dezember - also für 2021 im Dez 2020 | Letzte Abrechnung September/Oktober.
    Aber auch während des Jahres kommt es vor, dass nur abgerechnet (nicht geliefert) und nur geliefert (nicht abgerechnet wird).

    Edit: wenn ich mir keine Gedanken über Speicher etc. machen soll, halte ich ein speichern von Lieferung und Abrechnung in zwei DataTables für deutlich übersichtlicher. (Gerade weil die Kompkexität dieyer Tables ja deutlich zunehmen muss, im vgl. zu meiner erste Dts version)
    Ah. Jetzt hab ichs gerafft.
    Wenn ich vom Verein am 03.05. 20 Erwachsenenmarken und 20 Jugenmarken bekomme, erzeuge ich eine Lieferungrow und zwei Lieferpositionsrows. Wie gesagt, für mich ist das noch ganz schön abstrakt.
    Ich habe nun eine Table für Lieferung und eine für Abrechnung erstellt.
    Wie gesagt ich vermute, dass dies die Wart- und Lesbarkeit des Codes (im Vergleich zu einer einzigen Lieferung/Abrechnung Table) erhöht.
    So - was haltet ihr vom DataSet?

    Edit: Ich lese gerade, worauf ich bei der Verarbeitung der Kundendaten achten muss.
    Daraus ergeben sich 2 neue Punkte bei "was das Programm können soll (habe ich der Übersichtlichkeit halber im Originalpost ebenfalls ergänzt:
    • export der kompletten Daten, was über eine Person gespeichert wird
    Also die Adressdaten, sowie die Daten wann welche Marke verkauft wurde - quasi alles was "mein Programm über die Person weiß"
    • Die Datenbank oder eben die xml die das DataSet enthält muss verschlüsselt sein
    hier denke ich an eine Verschlüsselung mit dieser CryptoDings Bibliothek mit Passwort und dem Salt dingen da.Allerdings würde ich das Passowrt glaube ich im Code speichern. Denn bei jedem Start ein PW eingeben ist lästig.
    Bilder
    • DataSet.png

      148,58 kB, 1.310×783, 65 mal angesehen

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „DerSmurf“ ()

    Hmm. Das mit der Einkauftabelle verstehe ich nicht.
    Kannst du das Mal erklären?
    Weil Kopfrechnen kann ich gut, aber will ich nich. Und ich bin ja auch nicht der einzige, der die Marken an Kunden ausgibt...

    "Für Geldbeträge sollte man Datentyp Decimal nehmen."
    Stimmt. Das andere ich noch ab.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „DerSmurf“ ()

    na, wies jetzt ist, steht der Kunde an der Kasse mit 3 verschiedenen Marken.
    Dann suchst du den Kunden, und fügst ihm VerkaufteMarke1 hinzu - schliesst den Dialog wieder.
    Dann suchst du den Kunden, und fügst ihm VerkaufteMarke2 hinzu - schliesst den Dialog wieder.
    Dann suchst du den Kunden, und fügst ihm VerkaufteMarke3 hinzu - schliesst den Dialog wieder.
    Dann rechnest du im Kopf zusammen, wasses kostet, und er gibt dir das geld.

    Mit einer Tabelle Einkauf:
    Du suchst den Kunden, und fügst ihm einen Einkauf hinzu.
    Dem Einkauf wiederum fügst du VerkaufteMarke1, VerkaufteMarke2, VerkaufteMarke3 hinzu
    Dann liest du vom Einkauf ab, wasses kostet, und er gibt dir das geld.