Gewinn/Verlust mit SQL

[Thomas D.]

Hallo alle zusammen und einen Schönen Pfingstsonntag.

Ich hab da folgendes vor und brauch mal ein paar Tips wie ich das bewältigt bekomme.

Folgendes

Meiner einer hat ein wenig bei Ebay gehandelt, jetzt möchte ich doch gerne wissen was so manche AUktion mir an Gewinn oder Verlust gebracht hat.

Meine Tabellenstruktur sieht wie folgt aus.

1.) Tabelle hat den Namen einkaeufe, und beinhaltet dén Table arktikelnummer,ek und verkauft. In verkauft steht dann die Artikelnummer drin an dem die Ware verkauft wurde.

Beispiel : artikelnummer = 1234567890 ek = 20 verkauft = 1234567891

2.) Tabelle heisst gebühren dort befindet sich das Table Gesamt wo drin steht wieviel mir die Auktion gekostet hat. Beispiel: gesamt = 2,30

3.) Tabelle heisst verkaeufe dort drin befindet sich das table vk und die Artikelnummer Beispiel: vk = 27 Artikelnummer = 1234567891 also die selbe wie oben in Tabelle gebühren.

Die Rechnung ist eigentlich simpel.

vk aus Tabelle verkaeufe mit Artikelnummer, vergleiche diese mit Artikelnummer aus Tabelle einkaeufe mit Wert aus Table verkauft, subtrahiere vk - ek, gehe dann in Tabelle gebühren und vergleiche die Artikelnummer aus Tabelle verkauft mit der Artikelnummer aus gebühren, nehme den Wert aus table gesamt und subtrahiere diesen vom Restwert aus vk - ek.

Das nun mit einem SUM Befehl zusammen zu stellen bereitet mir ein wenig Kopfzerbrechen und brauch da mal Hilfe wie ich am besten anfangen kann.

Danke schön, erst einmal im vorraus.

Gruss Thomas

[ziegenmelker]

Hallo,

Das nun mit einem SUM Befehl zusammen zu stellen bereitet mir ein wenig Kopfzerbrechen und brauch da mal Hilfe wie ich am besten anfangen kann.

select sum(e.vk - v.vk -g.geb) as gewinn  
from einkauf e, verkauf v, gebuehren g  
where e.artikelnr = v.artikelnr  
and v.artikelnr = g.artikelnr

wahlweise noch zusätzlich mit
and v.vk > 0

um nichtverkaufte Artikel auszuschließen.
(Default im Feld vk muß dann aber 0 sein, sonst gegebenenfalls auf null abfragen.

cu,
ziegenmelker

[Thomas D.]

Hallo und schönen Dank

Hab es gerade mal getestet mit einem Datensatz, die Rechnung war zwar nicht ganz richtig, aber zumindest wusste ich nun wie ich es zusammen zu setzen habe.

Hier mein Ergebnis

select sum(v.vk - g.gesamt - e.ek) as gewinn
from einkaeufe e, verkaeufe v, gebuehren g
where e.verkauft = 6767649338 AND v.artikelnummer = 6767649338
AND g.artikelnummer = 6767649338

Machte immerhin 6 Euro aus -)))))

[Ludger]

Hi,

1.) Tabelle hat den Namen einkaeufe, und beinhaltet dén Table arktikelnummer,ek und verkauft. In verkauft steht dann die Artikelnummer drin an dem die Ware verkauft wurde.

Beispiel : artikelnummer = 1234567890 ek = 20 verkauft = 1234567891

2.) Tabelle heisst gebühren dort befindet sich das Table Gesamt wo drin steht wieviel mir die Auktion gekostet hat. Beispiel: gesamt = 2,30

3.) Tabelle heisst verkaeufe dort drin befindet sich das table vk und die Artikelnummer Beispiel: vk = 27 Artikelnummer = 1234567891 also die selbe wie oben in Tabelle gebühren.

nur noch was zum Datendesign. Ich habe mir in den letzten Jahren auch eine Einnahmen-/Ausgabenverwaltung zusammengefrickelt, darum kenne ich mich da ein wenig aus.   :-)

Also, ich schlage vor alle drei Tabellen zusammenzufuehren in eine Tabelle 'Buchungen'. Eine zweite Tabelle koennte 'Kategorien' heissen und anfaenglich die Datensaetze 'Einkauf', 'Gebuehr' und 'Verkauf' beinhalten. Das ist einfacher und darum auch besser.

Gruss,
Ludger

[Reiner]

Hi,

1.) Tabelle hat den Namen einkaeufe, und beinhaltet dén Table arktikelnummer,ek und verkauft. In verkauft steht dann die Artikelnummer drin an dem die Ware verkauft wurde.

Beispiel : artikelnummer = 1234567890 ek = 20 verkauft = 1234567891

2.) Tabelle heisst gebühren dort befindet sich das Table Gesamt wo drin steht wieviel mir die Auktion gekostet hat. Beispiel: gesamt = 2,30

3.) Tabelle heisst verkaeufe dort drin befindet sich das table vk und die Artikelnummer Beispiel: vk = 27 Artikelnummer = 1234567891 also die selbe wie oben in Tabelle gebühren.

nur noch was zum Datendesign. Ich habe mir in den letzten Jahren auch eine Einnahmen-/Ausgabenverwaltung zusammengefrickelt, darum kenne ich mich da ein wenig aus.   :-)

das ist ein Anachronismus in sich, gell?!

Also, ich schlage vor alle drei Tabellen zusammenzufuehren in eine Tabelle 'Buchungen'. Eine zweite Tabelle koennte 'Kategorien' heissen und anfaenglich die Datensaetze 'Einkauf', 'Gebuehr' und 'Verkauf' beinhalten. Das ist einfacher und darum auch besser.

Dito!
Nicht alles was einfacher aussieht, ist besser.
Generell ist eine Normalisierung der Daten der Weg, den man gehen sollte.
Das ist einfacher zu verstehen und braucht am wenigsten Speicherplatz.
Aber auch das kann man generell nicht immer umsetzen.
Wenn es z.B. um hohe Geschwindigkeiten geht, _kann_ es sinnvoll sein, Daten z.B. auch redundant in mehreren Tabellen zu halten.

Geschwindigkeit ist hier sicher nicht gefragt gewesen. Ich wollte nur auf Deine Pauschalisierung "einfacher=besser" eingehen.

Gruß
Reiner

[Ludger]

Hi,

Nicht alles was einfacher aussieht, ist besser.

es ist nicht einmal so, dass alles, was einfacher ist, wirtschaftlich gesehen besser ist. Aber, um unoetigen Diskussionen vorzubeugen (ich hasse den _vorzeitigen_ Einwand "Performance" im Datendesign), schlage ich vor Designfragen grundsaetzlich immer wie folgt zu bearbeiten:
1.) "Alles so einfach wie moeglich" (also keine Kompromisse)
2.) Denormalisieren wenn gute Gruende dafuer sprechen

Oft kommt man dann in der Diskussion gar nicht auf 2 zu sprechen. Uebrigens werden die Folgekosten bei denormalisierter Datenhaltung oft unbetrachtet gelassen. Schlecht skalierende, wartungsunfreundliche und kaum weiterentwicklungsfaehige Systeme koennten die Folge sein.

Wer hat schon mal ein voelig verhunztes System gesehen?

Geschwindigkeit ist hier sicher nicht gefragt gewesen. Ich wollte nur auf Deine Pauschalisierung "einfacher=besser" eingehen.

Danke fuer Deinen Beitrag!

Gruss,
Ludger

[Frank (no reg)]

Hallo,

meine Devise lautet seit einigen Jahren:

Keep it simple, as simple as possible but no simpler.
Zitat von A. Einstein, von (wann hab ich vergessen)

Denormalisierung empfiehlt sich m.E.n. hauptsächlich bei

• OLAP Anwendungen
• größtenteils schreibenden OLTP Anwendungen

Die Hintergründe brauch ich jetzt nicht näher erläutern.

Der Vorschlag von Ludger, die Vorgänge (sprich Buchungen) alle in einer Tabelle aufzubewahren und über eine andere Tabelle zu kategorisieren, ist einiges geeigneter, als dieselben Informationen in 2 voneinander unabhängigen Tabellen aufzubewahren, nur weil das eine Einnahmen und das andere Gewinne sind. Eine m:n Lösung für die Kategorisierung ist auch "besser" weil flexibler, manche Kosten kann man einfach mal mehreren Kostentypen zuordnen.

Ciao, Frank

[Ludger]

Hi,

Keep it simple, as simple as possible but no simpler.
Zitat von A. Einstein, von (wann hab ich vergessen)

dieses Zitat wird oft so verstanden, dass die Betonung auf dem zweiten Halbsatz vermutet wird, was leider falsch ist. Dennoch habe ich deshalb schon viele bittere Diskussionen gefuehrt. Ich empfehle das KISS - "keep it simple, stupid", aber das entspricht wohl nicht der deutschen Mentalitaet.   :-(

Eine m:n Lösung für die Kategorisierung ist auch "besser" weil flexibler, manche Kosten kann man einfach mal mehreren Kostentypen zuordnen.

Ich dachte eher an eine "1:n"-Beziehung.

Gruss,
Ludger

[Frank (no reg)]

Mahlzeit,

das no reg steht für no regular, weil:

• ich damit sehr schnell meine Postings wiederfinden kann (kein anderer hat so einen bescheuerten Nickname)
• irgendwer hat "Frank" als Namen mit Namensschutz versehen
• ich mich nicht als Regular dieses Forums sehe und betrachten möchte, dafür gibt es leider zuviele selfDarsteller hier, oder in deinen Worten (IIRC) Dumpfbacken ;-)

Für mich sagt das Zitat, versuch es nicht noch einfacher zu machen, als es in der Natur der Sache liegt.

Warum m:n ..
... du könntest Versandkosten als Kategorie haben, eBay Gebühren, Bankgebühren usw. und alles wären Overheadkosten. Wenn du mit einer Abfrage also alle Overheadkosten zusammenzählen willst, dann müsstest du die Summe für jede andere Kategorie bilden und diese dann wiederum summieren.

Alternativ gänge auch 1:n, wobei dann die Kategorien untereinander verschachtelt (verkettete Liste, Nested Set) werden, aber dies würde die Summierungs-Abfragen unvergleichbar komplizieren. Mehr komplizieren als beim Eintragen der Buchungen die mehrfache Kategoriezuweisung.

Ciao, Frank

[Ludger]

Hi,

• ich mich nicht als Regular dieses Forums sehe und betrachten möchte, dafür gibt es leider zuviele selfDarsteller hier, oder in deinen Worten (IIRC) Dumpfbacken ;-)

welche anderen Foren koenntest Du denn empfehlen?

Anmerkung: so schlimm ist es hier auch wieder nicht
:-)

Gruss,
Ludger

[Frank (no reg)]

Mahlzeit,

ich lese sehr häufig (und beteilige mich hin und wieder) in den teils moderierten Newsgroups zu SQL Server, .Net Entwicklung etc mit.

Es liegt ja hier auch nicht an der Masse sondern an der "Qualität" der Einzelnen. Siehe Archiv ;-) Daneben gibt es aber Leute hier in dem Raum die ich durchaus schätze :-). Und es ist mal ne Abwechslung für die Mittagspause.

Ciao, Frank

[Ludger]

Hi,

ich lese sehr häufig (und beteilige mich hin und wieder) in den teils moderierten Newsgroups zu SQL Server, .Net Entwicklung etc mit.

mal etwas spezifizieren bitte ...

Gruss,
Ludger

[Frank (no reg)]

Mahlzeit,

microsoft.public.de.*      (z.b. sqlserver, entwickler)

Die moderierten Newsgroups vom MSDN sind nur erreichbar wenn man eine Subscription hat und soweit mir bekannt auch nur darüber erreichbar

Ciao, Frank

[ziegenmelker]

Hallo,

nur noch was zum Datendesign. Ich habe mir in den letzten Jahren auch eine Einnahmen-/Ausgabenverwaltung zusammengefrickelt, darum kenne ich mich da ein wenig aus.   :-)

wenn man sowas zusammenfrickelt kennt man sich eher nicht aus.

Also, ich schlage vor alle drei Tabellen zusammenzufuehren in eine Tabelle 'Buchungen'. Eine zweite Tabelle koennte 'Kategorien' heissen und anfaenglich die Datensaetze 'Einkauf', 'Gebuehr' und 'Verkauf' beinhalten. Das ist einfacher und darum auch besser.

Warum einfach wenn's auch kompliziert geht. Neben den richtigen Dingen bezüglich Normalisierung und Geschwindigkeit die Reiner schon erwähnt hat, kann man hier noch anmerken, daß für diesen Zweck neben einem Blatt Papier und einem Bleistift ein Tabellenkalkulationsprogramm mehr als ausreichend wäre.
Dem OP ging es aber wohl eher um eine Übung bzgl. SQL.

cu,
ziegenmelker

[Ludger]

Hi,

nur noch was zum Datendesign. Ich habe mir in den letzten Jahren auch eine Einnahmen-/Ausgabenverwaltung zusammengefrickelt, darum kenne ich mich da ein wenig aus.   :-)

wenn man sowas zusammenfrickelt kennt man sich eher nicht aus.

UIs darf man zusammenfrickeln, mein Datendesign dagegen ist OK.

Warum einfach wenn's auch kompliziert geht. Neben den richtigen Dingen bezüglich Normalisierung und Geschwindigkeit die Reiner schon erwähnt hat, kann man hier noch anmerken, daß für diesen Zweck neben einem Blatt Papier und einem Bleistift ein Tabellenkalkulationsprogramm mehr als ausreichend wäre.

Das mit dem Tabellenkalkulationsprogramm ist reine Spekulation, den ersten Satz des obigen Absatzes habe ich auch nicht verstanden. War meine kleine Anmerkung etwas weiter oben denn unangebracht oder gar falsch?

Gruss,
Ludger

[ziegenmelker]

Hallo,

UIs darf man zusammenfrickeln, mein Datendesign dagegen ist OK.

das sehe ich nicht so, denn Fehler im UI können kaputte Datensätze verursachen. Benutzt du native oder per Software nachprogrammierte Transaktionen? Wenn nein, dann sollte dir klar sein, daß ein Programmcrash inkonsistente Daten verursachen kann, zumindest bei komplexeren Inserts/Updates wie sie in Finanzsoftware etc. vorkommen.

Warum einfach wenn's auch kompliziert geht. Neben den richtigen Dingen bezüglich Normalisierung und Geschwindigkeit die Reiner schon erwähnt hat, kann man hier noch anmerken, daß für diesen Zweck neben einem Blatt Papier und einem Bleistift ein Tabellenkalkulationsprogramm mehr als ausreichend wäre.

Das mit dem Tabellenkalkulationsprogramm ist reine Spekulation, ...

Nein, ich habe so schon weit komplexere Aufgaben bewältigt, z.B. ein komplettes Warenwirtschaftssystem.

... den ersten Satz des obigen Absatzes habe ich auch nicht verstanden. War meine kleine Anmerkung etwas weiter oben denn unangebracht oder gar falsch?

Wenn du die Umgestaltung der hier besprochenen Mini-DB meinst, dann nicht. Man könnte aber das Grunddesign dieser DB noch erheblich weiter abstrahieren, z.B. Währungscode, Konto, Personendaten, usw. usf.. Das hat aber mit der Frage des OP gar nichts mehr zu tun, sein Problem würde ich in einen Tabellenkalkulation lösen. Wenn ich ein Anfänger wäre und mich mit SQL und DB-Design beschäftigen wollte, würde ich mit einem guten Buch anfangen, denn ohne Theorie geht es imho nicht.

cu,
ziegenmelker

[Ludger]

Hi,

UIs darf man zusammenfrickeln, mein Datendesign dagegen ist OK.

das sehe ich nicht so, denn Fehler im UI können kaputte Datensätze verursachen.

eben nicht.

Benutzt du native oder per Software nachprogrammierte Transaktionen?

hanegt vom back end ab.

Wenn nein, dann sollte dir klar sein, daß ein Programmcrash inkonsistente Daten verursachen kann, zumindest bei komplexeren Inserts/Updates wie sie in Finanzsoftware etc. vorkommen.

Eben nicht.

Gruss,
Ludger

[ziegenmelker]

Hallo,

ich begebe mich jetzt mal (teilweise) auf dein Argumentationsniveau.

... mein Datendesign dagegen ist OK.

Das ist nicht nachprüfbar, aber ich möchte es auch nicht bezweifeln. ;-)

das sehe ich nicht so, denn Fehler im UI können kaputte Datensätze verursachen.

eben nicht.

Eben doch.

Benutzt du native oder per Software nachprogrammierte Transaktionen?

hanegt vom back end ab.

Also benutzt du _immer_ ein Transaktionsmanagement?

Wenn nein, dann sollte dir klar sein, daß ein Programmcrash inkonsistente Daten verursachen kann, zumindest bei komplexeren Inserts/Updates wie sie in Finanzsoftware etc. vorkommen.

Eben nicht.

Eben doch. Anmerkung: Unter "komplexeren..." verstehe ich die zusammengehörige Folge von mehreren Select/Insert/Update-Statements.

cu,
ziegenmelker

[Ludger]

Hi,

Benutzt du native oder per Software nachprogrammierte Transaktionen?

hanegt vom back end ab.

Also benutzt du _immer_ ein Transaktionsmanagement?

ja. So genante stored procedures. Dan kann man das UI durchaus "abhaengen" mit seiner Darstellungs- und work flow-Logik.

Gruss,
Ludger

[ziegenmelker]

Hallo,

ja. So genante stored procedures. Dan kann man das UI durchaus "abhaengen" mit seiner Darstellungs- und work flow-Logik.

natürlich ist das eine Verlagerung des Risikos weitmöglichst nach unten, trotzdem muß Finanzsoftware auch noch ein Verify der geschriebenen Daten machen, können natürlich wieder stored prcedures sein, aber die Anwendung darf Transaktionen erst dann valide erklären, wenn sie eine entsprechende Rückmeldung erhält, sonst könnten eventuell Millionenbeträge im Nirvana verschwinden, nur weil der DB-Server sich verschluckt, oder das IO-Subystem aus welchen Gründen auch immer versagt.
D.h. man kann das Risiko minimieren, aber nicht beseitigen und die Anwendung ist so oder so beteiligt, entweder weil sie selbst das Transaktionsmanegement übernehmen muß, weil z.B. das RDBMS es nicht selbst kann, oder weil die Rückmeldung verarbeitet werden muß.
Ich stimme dir aber zu, daß bei einer reinen korrekt implementierten Lösung über SPs die Anwendung ruhig "absemmeln" kann, denn die Rückmeldung ist ja nur ein Lesezugriff auf eine spezielle "Task"-Tabelle, jedenfalls habe ich das bisher so implementiert.

cu,
ziegenmelker

[Ludger]

Hi,

natürlich ist das eine Verlagerung des Risikos weitmöglichst nach unten, trotzdem muß Finanzsoftware auch noch ein Verify der geschriebenen Daten machen, können natürlich wieder stored prcedures sein, aber die Anwendung darf Transaktionen erst dann valide erklären, wenn sie eine entsprechende Rückmeldung erhält, sonst könnten eventuell Millionenbeträge im Nirvana verschwinden, nur weil der DB-Server sich verschluckt, oder das IO-Subystem aus welchen Gründen auch immer versagt.

was ist denn bitte ein VERIFY und welchen Nutzen soll das denn bringen? Es ist doch so, dass die angeforderte Transaktion ausgefuehrt wird oder auch nicht und dass die "Webanwendung" darueber Auskunft erhaelt, bzw. unter Umstaenden eben auch nicht, was aber auch kein Problem ist. Betrachtest Du das dann moeglicherweise erfolgende "Nachschauen" als VERIFY?

Gruss,
Ludger

[ziegenmelker]

Hallo,

Betrachtest Du das dann moeglicherweise erfolgende "Nachschauen" als VERIFY?

ja.

cu,
ziegenmelker