Morgen
Kann ich eine eigene Exception in Mysql werfen?
quasi so was:
....
IF ResourceCount > 1000 THEN
raise_count_error (-20100, 'more then 1000');
gibt es so etwas?
gefunden hab ich in der Doku nichts :(
grüße
Thomas
Thomas Butz schrieb:
> Kann ich eine eigene Exception in Mysql werfen?
>
> quasi so was:
> ....
>
>
> IF ResourceCount > 1000 THEN
> raise_count_error (-20100, 'more then 1000');
Wozu brauchst Du so etwas?
Gruß. Claus
Thomas Butz schrieb:
> Morgen
>
> Kann ich eine eigene Exception in Mysql werfen?
>
> quasi so was:
> ...
>
>
> IF ResourceCount > 1000 THEN
> raise_count_error (-20100, 'more then 1000');
>
>
> gibt es so etwas?
M.W.: Nein
> gefunden hab ich in der Doku nichts :(
Sag ich doch. Bislang behelfen sich die Leute soviel ich weiß mit
merkwürdigen Würgarounds.
Claus Reibenstein schrieb:
> Thomas Butz schrieb:
>
>> Kann ich eine eigene Exception in Mysql werfen?
>>
>> quasi so was:
>> ....
>>
>>
>> IF ResourceCount > 1000 THEN
>> raise_count_error (-20100, 'more then 1000');
>
> Wozu brauchst Du so etwas?
>
Wie wäre es mit "um einen Fehler an die Anwendung zurückliefern zu können"?
Christian Kirsch schrieb:
> Thomas Butz schrieb:
>> Morgen
>>
>> Kann ich eine eigene Exception in Mysql werfen?
>>
>> quasi so was:
>> ...
>>
>>
>> IF ResourceCount > 1000 THEN
>> raise_count_error (-20100, 'more then 1000');
>>
>>
>> gibt es so etwas?
>
>
> M.W.: Nein
>
>> gefunden hab ich in der Doku nichts :(
>
> Sag ich doch. Bislang behelfen sich die Leute soviel ich weiß mit
> merkwürdigen Würgarounds.
So ist es.
....
IF ResourceCount > 1000 THEN
SET newUniqueKeyfield = -1
END IF;
END;
Ein Trigger (BEFORE INSERT) ruft bei einem Insert die function die ein
count(*) durchführt wenn dabei ein zu großer Wert zurückkommt wird ein
Unique Key Value aus dem insert auf einen bereits existenten bzw.
ungültigen Wert gesetzt (NEW.unique_id = newUniqueKeyfield) und der
Insert geht schief ( # ERROR 1452 (23000): Cannot add or update a child
row: a foreign key constraint fails)
- sehr häßlich aber wenn es nicht besser geht ...
Grüße
Thomas
Hallo Claus,
> Wozu brauchst Du so etwas?
Als Ersatz für die fehlenden check constraints vermutlich. Weiterhelfen
könnte vielleicht:
http://dev.mysql.com/tech-resources/articles/mysql-storedpro cedures.pdf
Siegfried
--
http://www.schmidt.ath.cx
Christian Kirsch schrieb:
> Claus Reibenstein schrieb:
>
>> Thomas Butz schrieb:
>>
>>> Kann ich eine eigene Exception in Mysql werfen?
>>>
>>> IF ResourceCount > 1000 THEN
>>> raise_count_error (-20100, 'more then 1000');
¯¯¯¯
More _than_ 1000.
>> Wozu brauchst Du so etwas?
>
> Wie wäre es mit "um einen Fehler an die Anwendung zurückliefern zu können"?
Warum soll die Datenbank einen Fehler generieren und an die Anwendung
liefern, wenn doch gar kein Datenbankfehler vorliegt? Die Prüfung
bestimmter Limitierungen der Anwendung (im Beispiel die Begrenzung auf
1000 Datensätze) ist Aufgabe der Anwendung, nicht der Datenbank. Warum
also generiert die Anwendung nicht selber entsprechende Fehler?
Ich sehe keinen Sinn darin, so etwas innerhalb der Datenbank machen zu
wollen. Deshalb meine Frage.
Gruß. Claus
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Claus Reibenstein schrieb:
>>> Wozu brauchst Du so etwas?
>> Wie wäre es mit "um einen Fehler an die Anwendung zurückliefern zu können"?
>
> Warum soll die Datenbank einen Fehler generieren und an die Anwendung
> liefern, wenn doch gar kein Datenbankfehler vorliegt? Die Prüfung
> bestimmter Limitierungen der Anwendung (im Beispiel die Begrenzung auf
> 1000 Datensätze) ist Aufgabe der Anwendung, nicht der Datenbank. Warum
> also generiert die Anwendung nicht selber entsprechende Fehler?
>
> Ich sehe keinen Sinn darin, so etwas innerhalb der Datenbank machen zu
> wollen. Deshalb meine Frage.
ganz kurz: Es sollen nicht mehr als n Einträge einer bestimmten form pro
User anlegbar sein. Das auf Lesen hoch optimierte Schema läßt keine
andere Lösung zu als über ein Select count(*) mit einer bestimmten where
Bedingung die Anzahl auszulesen und darauf zu reagieren. Die Appl.
interessiert das nicht die will nur anlegen oder nicht anlegen - sprich
der insert geht gut wenn nicht hat das seine Gründe (exceptions sind
nicht per default böse ;)....
grüße
thomas
Thomas Butz schrieb:
> Claus Reibenstein schrieb:
>
>> Ich sehe keinen Sinn darin, so etwas innerhalb der Datenbank machen zu
>> wollen. Deshalb meine Frage.
>
> ganz kurz: Es sollen nicht mehr als n Einträge einer bestimmten form pro
> User anlegbar sein. Das auf Lesen hoch optimierte Schema läßt keine
> andere Lösung zu als über ein Select count(*) mit einer bestimmten where
> Bedingung die Anzahl auszulesen und darauf zu reagieren. Die Appl.
> interessiert das nicht die will nur anlegen oder nicht anlegen - sprich
> der insert geht gut wenn nicht hat das seine Gründe (exceptions sind
> nicht per default böse ;)....
Ganz kurz: Designfehler der Applikation.
Etwas länger: Das sieht mir nach einem Designfehler der Applikation aus.
Wenn ein Benutzer damit nur maximal n Einträge anlegen können soll, muss
die Applikation das eben abfangen. Tut sie es nicht, ist sie kaputt.
Gruß. Claus
Claus Reibenstein schrieb:
> Thomas Butz schrieb:
>
>> Claus Reibenstein schrieb:
>>
>>> Ich sehe keinen Sinn darin, so etwas innerhalb der Datenbank machen zu
>>> wollen. Deshalb meine Frage.
>> ganz kurz: Es sollen nicht mehr als n Einträge einer bestimmten form pro
>> User anlegbar sein. Das auf Lesen hoch optimierte Schema läßt keine
>> andere Lösung zu als über ein Select count(*) mit einer bestimmten where
>> Bedingung die Anzahl auszulesen und darauf zu reagieren. Die Appl.
>> interessiert das nicht die will nur anlegen oder nicht anlegen - sprich
>> der insert geht gut wenn nicht hat das seine Gründe (exceptions sind
>> nicht per default böse ;)....
>
> Ganz kurz: Designfehler der Applikation.
mag sein (wenn auch in diesem Punkt eher nicht - das jetzt zu erläutern
hat auch nichts mehr mit dem Thema zu tun sndern eher mit trees in
sql..)- spielt aber bezgl. der Frage keine Rolle.
grüße
Thomas
On Tue, 18 Sep 2007 13:35:55 +0200, Claus Reibenstein wrote:
> Thomas Butz schrieb:
>
>> Claus Reibenstein schrieb:
>>
>>> Ich sehe keinen Sinn darin, so etwas innerhalb der Datenbank machen zu
>>> wollen. Deshalb meine Frage.
>>
>> ganz kurz: Es sollen nicht mehr als n Einträge einer bestimmten form
>> pro User anlegbar sein. Das auf Lesen hoch optimierte Schema läÃt keine
>> andere Lösung zu als über ein Select count(*) mit einer bestimmten
>> where Bedingung die Anzahl auszulesen und darauf zu reagieren. Die
>> Appl. interessiert das nicht die will nur anlegen oder nicht anlegen -
>> sprich der insert geht gut wenn nicht hat das seine Gründe (exceptions
>> sind nicht per default böse ;)....
>
> Ganz kurz: Designfehler der Applikation.
>
> Etwas länger: Das sieht mir nach einem Designfehler der Applikation aus.
> Wenn ein Benutzer damit nur maximal n Einträge anlegen können soll, muss
> die Applikation das eben abfangen. Tut sie es nicht, ist sie kaputt.
Quark. Das hat mit der Anwendung nix zu tun. Wenn eine zweite, dritte
oder zwölfte Anwendung auf die Datenbank zugreift ändert sich an der
Beschränkung ja so ca. gar nichts. Das ist eine Einschränkung des
Schemas. Gültige Datenbankzustände umfassen halt max. X Einträge pro
Benutzer und wenn _irgendeine_ Anwendung (und sei es nen Benutzer der
direkt SQL absetzen kann) versucht nen Eintrag mehr einzufügen, dann
würde das einen ungültigen Datenbankzustand erzeugen. Und ungültige
Datenbankzustände sollten vom DBMS zurückgewiesen werden, und darauf
sollte sich eine Anwendung auch verlassen können, und nicht selber drüber
nachdenken müssen, ob man XY denn jetzt mit der Datenbank machen darf.
IMHO unterscheidet sich das 1000 Zeilen-Limit nur um einen Faktor 1000
von einem Unique Index, und über dessen Sinn und Zweck beschwerst du dich
ja auch nicht, oder?
Björn
Claus Reibenstein wrote:
> Thomas Butz schrieb:
>
>> Claus Reibenstein schrieb:
>>
>>> Ich sehe keinen Sinn darin, so etwas innerhalb der Datenbank machen
>>> zu wollen. Deshalb meine Frage.
>>
>> ganz kurz: Es sollen nicht mehr als n Einträge einer bestimmten form
>> pro User anlegbar sein. Das auf Lesen hoch optimierte Schema läßt
>> keine andere Lösung zu als über ein Select count(*) mit einer
>> bestimmten where Bedingung die Anzahl auszulesen und darauf zu
>> reagieren. Die Appl. interessiert das nicht die will nur anlegen
>> oder nicht anlegen - sprich der insert geht gut wenn nicht hat das
>> seine Gründe (exceptions sind nicht per default böse ;)....
>
> Ganz kurz: Designfehler der Applikation.
>
> Etwas länger: Das sieht mir nach einem Designfehler der Applikation
> aus. Wenn ein Benutzer damit nur maximal n Einträge anlegen können
> soll, muss die Applikation das eben abfangen. Tut sie es nicht, ist
> sie kaputt.
>
Das sehe ich so nicht, was eine Datenbank tun kann um die Daten konsistent
zu halten, sollte sie auch tun. Oder machen für dich andere Constraints wie
Foreign Keys auch keinen Sinn? Vielleicht ist MySQL noch nicht so weit, aber
deswegen ist das kein Fehler die Application. Möglicherweise muss man es
hier in der Application lösen, weil es MySQL nicht kann. Besser wird es
dadurch aber nicht.
Christian
Claus Reibenstein schrieb:
....
>
> Ganz kurz: Designfehler der Applikation.
So was zu beurteilen ohne die Applikation zu kennen ist nicht adäquat!
> Etwas länger: Das sieht mir nach einem Designfehler der Applikation aus.
> Wenn ein Benutzer damit nur maximal n Einträge anlegen können soll, muss
> die Applikation das eben abfangen. Tut sie es nicht, ist sie kaputt.
Was im Backend gemacht werden kann, sollte auch da gemacht werden.
Es kann gut möglich sein das n-Tier(e) auf die Tabelle zugreifen. Durch
eine zentrale Behandlung minimiert man mögliche Fehlerfälle.
Thomas Butz schrieb:
....
> Ein Trigger (BEFORE INSERT) ruft bei einem Insert die function die ein
> count(*) durchführt wenn dabei ein zu groÃer Wert zurückkommt wird ein
....
btw, Vorsicht bei count(*) in Verbindung mit InnoDB.
http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.h tml
InnoDB does not keep an internal count of rows in a table. (In practice,
this would be somewhat complicated due to multi-versioning.) To process
a SELECT COUNT(*) FROM t statement, InnoDB must scan an index of the
table, which takes some time if the index is not entirely in the buffer
pool. To get a fast count, you have to use a counter table you create
yourself and let your application update it according to the inserts and
deletes it does. If your table does not change often, using the MySQL
query cache is a good solution. SHOW TABLE STATUS also can be used if an
approximate row count is sufficient. See Section 13.2.11, âInnoDB
Performance Tuning Tipsâ.
Also beim counten, *eventuell* lieber einen Trigger bauen, der mitzählt.
Claus Reibenstein <4spammersonly@web.de> wrote:
> Christian Kirsch schrieb:
>
>> Wie wäre es mit "um einen Fehler an die Anwendung zurückliefern zu können"?
>
> Warum soll die Datenbank einen Fehler generieren und an die Anwendung
> liefern, wenn doch gar kein Datenbankfehler vorliegt? Die Prüfung
> bestimmter Limitierungen der Anwendung (im Beispiel die Begrenzung auf
> 1000 Datensätze) ist Aufgabe der Anwendung, nicht der Datenbank. Warum
> also generiert die Anwendung nicht selber entsprechende Fehler?
Ich weiss ja nicht, wie du zwischen einer Anwendung und der formalen
Definition deiner Daten unterscheidest, aber du solltest diesen Punkt
noch einmal überdenken.
Wenn die Definition vorsieht, das es n (mit n > 1) Datensätze geben kann,
aber nur maximal n <= 1000 vorkommen dürfen, so ist dies formal richtig.
Die Datenbank hat nun sicherzustellen, das dies auch eingehalten wird.
Für n <= 1 klappt dies mit UNIQUE ja auch, ich sehe hier keinen großen
Unterschied, ob n nun nur einmal oder mehrfach vorkommen darf.
> Ich sehe keinen Sinn darin, so etwas innerhalb der Datenbank machen zu
> wollen. Deshalb meine Frage.
Du hast imho nicht wirklich verstanden, warum man das RDBMS und nicht
DBSS (für S wie Storage) nennt. Geh wieder mit Textfiles spielen, da
darfst du dich selber um die Validierung deiner Daten kümmern.
Bye
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
Claus Reibenstein <4spammersonly@web.de> wrote:
> Christian Kirsch schrieb:
>> Claus Reibenstein schrieb:
>>> Wozu brauchst Du so etwas?
>>
>> Wie wäre es mit "um einen Fehler an die Anwendung zurückliefern zu können"?
>
> Warum soll die Datenbank einen Fehler generieren und an die Anwendung
> liefern, wenn doch gar kein Datenbankfehler vorliegt? Die Prüfung
> bestimmter Limitierungen der Anwendung (im Beispiel die Begrenzung auf
> 1000 Datensätze) ist Aufgabe der Anwendung, nicht der Datenbank.
Das stimmt in dem Moment nicht mehr, wo Teile der Anwendung in Form
von stored procedures *in* der Datenbank ausgeführt werden. Man mag
geteilter Meinung sein, ob Anwendungslogik in stored procedures gehört
oder nicht. Aber wenn es *möglich* ist das zu tun, muß es auch möglich
sein Fehler in geregelter Form nach oben zu melden.
XL
On Tue, 18 Sep 2007 14:07:59 +0200, Harald Stowasser wrote:
> Thomas Butz schrieb:
>
> ...
>> Ein Trigger (BEFORE INSERT) ruft bei einem Insert die function die ein
>> count(*) durchführt wenn dabei ein zu groÃer Wert zurückkommt wird ein
> ...
>
> btw, Vorsicht bei count(*) in Verbindung mit InnoDB.
Da er ja eh eine Bedingung für die zu zählenden Zeilen spezifiziert, ist
InnoDB da egal. Sobald eine Bedingung gegeben ist, muss auch bei MyISAM
Tabellen "echt" gezählt werden, der gespeicherte Wert bezieht sich ja nur
auf die Anzahl aller Zeilen in der Tabelle.
Björn
Am Dienstag, den 18.09.2007, 09:40 +0200 schrieb Thomas Butz:
> Kann ich eine eigene Exception in Mysql werfen?
> ...
> IF ResourceCount > 1000 THEN
> raise_count_error (-20100, 'more then 1000');
Noch nicht erwäht wurde der Workaround, eine nicht existierende Stored
Proc. aufzurufen.
Gruß,
Joachim