Berechnungsfeld erstellen

Hallo,

ich möchte in meiner MySQL-Datenbank ein sogenanntes Berechnungsfeld
erstellen, d.h. in diesem Feld soll automatisch die Summe aus Werten von
anderen Feldern errechnet werden.

Habe bisher nirgends Info's darüber gefunden. Ist das in MySQL überhaupt
möglich und wenn ja, wie?

Gruß
Andreas

Re: Berechnungsfeld erstellen

Thomas Berndt wrote:

> Hallo,
>
> ich möchte in meiner MySQL-Datenbank ein sogenanntes Berechnungsfeld
> erstellen, d.h. in diesem Feld soll automatisch die Summe aus Werten von
> anderen Feldern errechnet werden.

In einer Tabelle?

Zusätzliches Feld mit alter table anlegen, dann:

update tabelle set neues_feld = feld_1 + feld_2 + feld_n WHERE ...

In einer Abfrage machst Du einfach nur sowas:

SELECT feld_1, feld_2, feld_1 + feld_2 as summe from tabelle WHERE ...

> Habe bisher nirgends Info's darüber gefunden. Ist das in MySQL überhaupt
> möglich und wenn ja, wie?

Du kannst alles moegliche in Queries berechnen und das Ergebnis auch
speichern, wenn Du ein Update der Tabelle wie oben machst. Ob Du die
Speicherung brauchst, sei dahingestellt.

Wolfgang

Re: Berechnungsfeld erstellen

Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)

Re: Berechnungsfeld erstellen

Wolfgang Kueter wrote:

> Thomas Berndt wrote:
>
>> Hallo,
>>
>> ich möchte in meiner MySQL-Datenbank ein sogenanntes Berechnungsfeld
>> erstellen, d.h. in diesem Feld soll automatisch die Summe aus Werten von
>> anderen Feldern errechnet werden.
>
>
> Zusätzliches Feld mit alter table anlegen, dann:
>
> update tabelle set neues_feld = feld_1 + feld_2 + feld_n WHERE ...
>
> In einer Abfrage machst Du einfach nur sowas:
>
> SELECT feld_1, feld_2, feld_1 + feld_2 as summe from tabelle WHERE ...
>
>> Habe bisher nirgends Info's darüber gefunden. Ist das in MySQL überhaupt
>> möglich und wenn ja, wie?
>
> Du kannst alles moegliche in Queries berechnen und das Ergebnis auch
> speichern, wenn Du ein Update der Tabelle wie oben machst. Ob Du die
> Speicherung brauchst, sei dahingestellt.

Wenn das Feld einmal berechnet ist, bleibt es so im jeweiligen Datensatz. Es
wird sich dann nichts mehr ändern.

Re: Berechnungsfeld erstellen

On Sun, 04 Sep 2005 13:49:09 +0200, Thomas Berndt wrote:

> ich möchte in meiner MySQL-Datenbank ein sogenanntes Berechnungsfeld
> erstellen, d.h. in diesem Feld soll automatisch die Summe aus Werten von
> anderen Feldern errechnet werden.

Für Views brauchst Du Mysql 5.

Gruß,
Joachim

Re: Berechnungsfeld erstellen

Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)

Re: Berechnungsfeld erstellen

Andreas Kretschmer wrote:

> begin Thomas Berndt wrote:
>>> Du kannst alles moegliche in Queries berechnen und das Ergebnis auch
>>> speichern, wenn Du ein Update der Tabelle wie oben machst. Ob Du die
>>> Speicherung brauchst, sei dahingestellt.
>
>> Wenn das Feld einmal berechnet ist, bleibt es so im jeweiligen Datensatz.
>> Es wird sich dann nichts mehr ändern.
>
> Dies war allerdings keine Antwort auf die Frage. Und die Frage, die sich
> nun erst recht stellt: warum etwas in der DB speichern, was komplett
> redundant ist? Du kannst jederzeit mit einem simplen SELECT Dir eine
> Tabelle mit den Spalten + der Summe geben lassen, wozu redundante Daten
> extra speichern?
>
>
> end
> Andreas

Irgendwie habe ich einige Probleme das Ganze zu verstehen und möchte das
Problem mal genauer definieren.

Ich habe einen Artikel, der als Datensatz in einer Artikeldatenbank
enthalten ist. Für diesen gibt es einen Einkaufspreis. Nun möchte ich ein
Feld anlegen, in dem der VK-Preis automatisch errechnet wird. Dazu gibt es
einzelne Felder mit Beschaffungskosten, MwSt. etc. die auf den EK-Preis
automatisch aufgeschlagen werden. Und als Ergebnis gibt es dann den
VK-Preis. Und der bleibt ja dann gleich.

Re: Berechnungsfeld erstellen

Thomas Berndt wrote:
> Ich habe einen Artikel, der als Datensatz in einer Artikeldatenbank
> enthalten ist. Für diesen gibt es einen Einkaufspreis. Nun möchte ich ein
> Feld anlegen, in dem der VK-Preis automatisch errechnet wird. Dazu gibt es
> einzelne Felder mit Beschaffungskosten, MwSt. etc. die auf den EK-Preis
> automatisch aufgeschlagen werden. Und als Ergebnis gibt es dann den
> VK-Preis. Und der bleibt ja dann gleich.

Ich habe das gleiche "Problem", es aber anders gelöst:
Ein automatisch berechneter Verkaufspreis ist seltenst das, was "man"
als Verkäufer auch wirklich verlangen möchte. Da spielen dann zu schnell
Dinge mit herein wie häßliche Nachkommastellen, Puffer für zukünftige
Preiserhöhungen und ähnliches.
Dazu kommt, dass der Einkaufspreis in seltenen Fällen a priori
feststeht, da man Artikel über mehrere Lieferanten und zu verschieden
Konditionen je nach Menge bekommt.

Ich biete dafür einen aktuell gehaltenen, gemittelten Einkaufspreis über
den aktuellen Lagerbestand an. Das heißt, bestellt man zwischendurch mal
zu erhöhten Preisen, wird der aktuelle Einkaufspreis für die Zeit, in
der diese Artikel real existieren entsprechend erhöht (ich gehe dabei
von einem FIFO-Lager aus).

Da diese Schwankungen nicht in den Verkaufspreis einfließen sollten (wer
möchte im Allgemeinen schon tagesaktuelle Preise) ist der Verkaufspreis
ein editierbares Feld. Innerhalb der Applikation wird dann eine
Berechnungshilfe bereitgestellt, die Mehrwertsteuersätze und andere
Faktoren berücksichtigt.
Selbst, wenn man die Preise automatisiert erstellen lassen möchte, kann
das die Applikation einmal erledigen und sollte anschließend noch die
Möglichkeit des manuellen Editierens bereitstellen.

MaW, das Feld "Verkaufspreis" sollte meiner Meinung nach alles andere
als "fest" sein.

HTH und Grüße
Kai

--
This signature is left as an exercise for the reader.

Re: Berechnungsfeld erstellen

Moiners,

Thomas Berndt wrote:

> Irgendwie habe ich einige Probleme das Ganze zu verstehen und möchte das
> Problem mal genauer definieren.

Danke ;)

> Ich habe einen Artikel, der als Datensatz in einer Artikeldatenbank
> enthalten ist. Für diesen gibt es einen Einkaufspreis. Nun möchte ich ein
> Feld anlegen, in dem der VK-Preis automatisch errechnet wird. Dazu gibt es
> einzelne Felder mit Beschaffungskosten, MwSt. etc. die auf den EK-Preis
> automatisch aufgeschlagen werden. Und als Ergebnis gibt es dann den
> VK-Preis. Und der bleibt ja dann gleich.

Nein, bleibt er nicht. Evt. schonmal daran gedacht, dass sich die
Mehrwertsteuer ändern könnte?

Eigentlich hast Du zwei Möglichkeiten. Wie andere schon schrieben könntest
Du den VK im select berechnen ("select EK*Handelsspanne*MwSt as VK
from ...") oder du schreibst eine View (ab 5.01), die die Felder Deiner
Ursprungstabelle plus das berechnete Feld enthält.
http://dev.mysql.com/doc/mysql/en/create-view.html

HTH

Niki

--
Why is "256 ways to make love" the most famous book on the internet?
It's the "Fucking Manual".

Re: Berechnungsfeld erstellen

Niki Hansche wrote:

> Moiners,
>
> Thomas Berndt wrote:
>
>> Irgendwie habe ich einige Probleme das Ganze zu verstehen und möchte das
>> Problem mal genauer definieren.
>
> Danke ;)
>
>> Ich habe einen Artikel, der als Datensatz in einer Artikeldatenbank
>> enthalten ist. Für diesen gibt es einen Einkaufspreis. Nun möchte ich ein
>> Feld anlegen, in dem der VK-Preis automatisch errechnet wird. Dazu gibt
>> es einzelne Felder mit Beschaffungskosten, MwSt. etc. die auf den
>> EK-Preis automatisch aufgeschlagen werden. Und als Ergebnis gibt es dann
>> den VK-Preis. Und der bleibt ja dann gleich.
>
> Nein, bleibt er nicht. Evt. schonmal daran gedacht, dass sich die
> Mehrwertsteuer ändern könnte?
>
Klar, aber die ändert sich ja nicht allzu oft. ;)

Man kann das Problem auch auf ein Bestellformular beziehen. Der Kunde
bestellt fünf Artikel, aufgeführt ist jeweils der Einzelpreis. Nun möchte
ich ein Berechnungsfeld in dem aus diesen fünf Artikeln der Gesamtpreis
berechnet wird. Und der bleibt ja dann gleich.

Arbeite übrigens mit XAMPP für Linux, und da ist MySQL 4 integriert. Noch
keine Version 5. :(

Andreas

Re: Berechnungsfeld erstellen

Thomas Berndt schrieb im Newsbeitrag
>> Nein, bleibt er nicht. Evt. schonmal daran gedacht, dass
>> sich die Mehrwertsteuer ändern könnte?
> Klar, aber die ändert sich ja nicht allzu oft. ;)

Das schon, aber ein VK ist keine Konstante - der eine kann die
Mehrwertsteuer ausklammern, der andere nicht. Bei bestimmten Produkten
(Büchern) gilt ein ermäßigter Mehrwertsteuersatz, usw.

Ich würde EK und VK (ohne MwSt.) in getrennten Feldern vorhalten und
die MwSt. bei Bedarf in die Ausgabe reinrechnen. Bei
Integer-Arithmetik mit entsprechender Bibliothek für große Zahlen
(d.h. Berechnungen auf Cent-Basis) sollten Rundungsprobleme nicht so
störend sein (die Abrundung kann man bei der VK-Berechnung
entsprechend einrechnen, so dass man sich nicht ins Fleisch schneidet
....). Lustig wird's, wenn Du Deinen VK in Sfr. oder andere Währungen
umrechnen darfst ;-)

So long,
-+- Dirk -+-

Re: Berechnungsfeld erstellen

Thomas Berndt wrote:

> Man kann das Problem auch auf ein Bestellformular beziehen. Der Kunde
> bestellt fünf Artikel, aufgeführt ist jeweils der Einzelpreis. Nun möchte
> ich ein Berechnungsfeld in dem aus diesen fünf Artikeln der Gesamtpreis
> berechnet wird. Und der bleibt ja dann gleich.

Ich glaube, dir ist einfach der Unterschied zwischen einer Datenbank und
einer Tabellenkalkulation nicht klar. Abgeleitete Daten haben in einer
Datenbank nichts zu suchen. Punkt.


XL

Re: Berechnungsfeld erstellen

Axel Schwenke wrote:

> Ich glaube, dir ist einfach der Unterschied zwischen einer Datenbank und
> einer Tabellenkalkulation nicht klar. Abgeleitete Daten haben in einer
> Datenbank nichts zu suchen. Punkt.

Na ja, in Prinzip ist das natürlich korrekt, aber wenn man bspw. eine
Fakturierung schreibt, dann kann man es IMHO verantworten, sowas die die
Gesamtsumme einer Rechnung in der DB zu speichern. Zumindest erleichtert
einem das den Umgang mit alten Rechnungen nach der nächsten Erhöhung der
Mehrwertsteuer.

;-)

Wolfgang

Re: Berechnungsfeld erstellen

Wolfgang Kueter wrote:
> Axel Schwenke wrote:
>
>
>>Ich glaube, dir ist einfach der Unterschied zwischen einer Datenbank und
>>einer Tabellenkalkulation nicht klar. Abgeleitete Daten haben in einer
>>Datenbank nichts zu suchen. Punkt.
>
>
> Na ja, in Prinzip ist das natürlich korrekt, aber wenn man bspw. eine
> Fakturierung schreibt, dann kann man es IMHO verantworten, sowas die die
> Gesamtsumme einer Rechnung in der DB zu speichern. Zumindest erleichtert
> einem das den Umgang mit alten Rechnungen nach der nächsten Erhöhung der
> Mehrwertsteuer.

Ja, dann legst du diesen Wert allerdings bei der Rechnung, und nicht
beim Auftrag ab. Denn Teilrechnungen und ähnlichen Kram gibts ja auch noch.
Du hast allerdings recht damit, wenn du darauf hinaus wolltest, dass es
Daten gibt, die gespeichert werden sollten, obwohl sie
berechnet/abgeleitet sind.
Als Beispiel nocheinmal der Einkaufspreis. In dem Moment, in dem du
einen Auftrag anlegst, ist der Einkaufspreis bekannt. In einem Jahr hat
der aktuelle Einkaufspreis allerdings nichts mehr mit dem alten Auftrag
zu tun und eine statistische Auswertung fiele entsprechend schwer.
Das sind allerdings Dinge, die man sich _sehr_ genau überlegen sollte
und bei denen man sehr schnell "auf die schiefe Bahn" gerät, wenn man
einmal angefangen hat.

> ;-)

Ich weiß nicht, aber in letzter Zeit werden zwinkernde Smileys bei mir
immer mehr zu einem roten Tuch. Meinst du nicht ernst, was du sagst?
Möchtest du nicht ernstgenommen werden? Ist es gar Ironie, die du benutzt?

Grüße
Kai

--
This signature is left as an exercise for the reader.

Re: Berechnungsfeld erstellen

Wolfgang Kueter wrote:
> Axel Schwenke wrote:
>
>> Ich glaube, dir ist einfach der Unterschied zwischen einer Datenbank und
>> einer Tabellenkalkulation nicht klar. Abgeleitete Daten haben in einer
>> Datenbank nichts zu suchen. Punkt.
>
> Na ja, in Prinzip ist das natürlich korrekt, aber wenn man bspw. eine
> Fakturierung schreibt, dann kann man es IMHO verantworten, sowas die die
> Gesamtsumme einer Rechnung in der DB zu speichern.

Das ist ja auch etwas ganz anderes. Ich würde in den verschiedenen
Stadien einer Online-Shop-Applikation unterscheiden zwischen:

- Warenkorb (on-the-fly berechnete Summe)
- Auftrag (fixe Endsumme, enthält Spezialitäten wie Rabatte, d.h. ist
öfters nicht einfach die Summe der Einzelpreise)
- Rechnung (über den Auftragswert, evtl. wieder mit Spezialitäten wie
Skonto)

Natürlich haben diese Objekte etwas miteinander zu tun, aber die
Übergänge sind genau definiert und gehen auch immer nur in eine
Richtung.


XL