Hi,

für die Validierung von Zahlen vor der Speicherung in einer MySQL
Datenbank müsste ich prüfen, ob diese in dem Wertebereich der jeweiligen
Datentypen liegen (Integer, Bigint, Double). Gibt es eine Möglichkeit,
diese Zahlen über PHP (mysqli verwende ich derzeit) direkt zu ermitteln?
Denn gerade der Wertebereich von Double ist ja vom System her abhängig.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> für die Validierung von Zahlen vor der Speicherung in einer MySQL
> Datenbank müsste ich prüfen, ob diese in dem Wertebereich der jeweiligen
> Datentypen liegen (Integer, Bigint, Double). Gibt es eine Möglichkeit,
> diese Zahlen über PHP (mysqli verwende ich derzeit) direkt zu ermitteln?
> Denn gerade der Wertebereich von Double ist ja vom System her abhängig.

Sry wegen dem unpassenden Betreff. Hatte erst eine andere Frage und mir
ist erst danach eingefallen, dass es vielleicht besser wäre die
Wertebereiche von der MySQL Datenbank direkt abzufragen. :)

Meine Ursprüngliche Frage war nämlich wie ich sehr große Zahlen in PHP
am sinnvollsten schreibe, weil ich mit so Zahlen wie 1,445....E+200
vorher noch nichts zu tun hatte und wie man diese am besten schreibt,
sodass man noch mit denen rechnen bzw. vergleichen kann. Aber wenn ich
die Werte direkt abrufen könnte wäre das natürlich noch besser.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Christoph Herrmann schrieb:
>> für die Validierung von Zahlen vor der Speicherung in einer MySQL
>> Datenbank müsste ich prüfen, ob diese in dem Wertebereich der
>> jeweiligen Datentypen liegen (Integer, Bigint, Double). Gibt es eine
>> Möglichkeit, diese Zahlen über PHP (mysqli verwende ich derzeit)
>> direkt zu ermitteln? Denn gerade der Wertebereich von Double ist ja
>> vom System her abhängig.
>
> Sry wegen dem unpassenden Betreff. Hatte erst eine andere Frage und mir
> ist erst danach eingefallen, dass es vielleicht besser wäre die
> Wertebereiche von der MySQL Datenbank direkt abzufragen. :)
>
> Meine Ursprüngliche Frage war nämlich wie ich sehr große Zahlen in PHP
> am sinnvollsten schreibe, weil ich mit so Zahlen wie 1,445....E+200
> vorher noch nichts zu tun hatte und wie man diese am besten schreibt,
> sodass man noch mit denen rechnen bzw. vergleichen kann. Aber wenn ich
> die Werte direkt abrufen könnte wäre das natürlich noch besser.

Die wichtigere Frage ist wohl eher mit welcher *Genauigkeit* du die Zahl
speichern möchtest.

Harald Stowasser schrieb:
> Die wichtigere Frage ist wohl eher mit welcher *Genauigkeit* du die Zahl
> speichern möchtest.

Im Prinzip so genau wie möglich. Allerdings wenn der Wertebereich
schwankt ist mir Sicherheit wichtiger, weswegen ich dann den
kleinstmöglichen Wertebereich bevorzugen würde, der auf jeden Fall zu
speichern geht (Es soll vor allem SQL Fehlern vorgebeugt werden).

Bzw. falls damit die Anzahl der Nachkommastellen meinst, gute Frage...
Am besten wäre es, wenn es Variable ist.

Muss doch eine einfache Möglichkeit geben zu überprüfen ob eine Zahl im
Wertebereich des Datentypes der Datenbank liegt. Oder bin ich der
einzige der sowas braucht? :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:

> Muss doch eine einfache Möglichkeit geben zu überprüfen ob eine Zahl im
> Wertebereich des Datentypes der Datenbank liegt.

Gibt es: Einfach speichern und Fehlerstatus prüfen :-)

Gruß. Claus

Claus Reibenstein schrieb:
> Gibt es: Einfach speichern und Fehlerstatus prüfen :-)

Mmh, das wär die schlechteste Wahl finde ich ^^. Ich würde es gerne
Prüfen bevor ich es speichere, damit ich eine richtige Meldung ausgeben
kann an den Benutzer.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:

> für die Validierung von Zahlen vor der Speicherung in einer MySQL
> Datenbank müsste ich prüfen, ob diese in dem Wertebereich der jewei=
ligen
> Datentypen liegen (Integer, Bigint, Double). Gibt es eine Möglichkeit=
,
> diese Zahlen über PHP (mysqli verwende ich derzeit) direkt zu ermitte=
ln?
> Denn gerade der Wertebereich von Double ist ja vom System her abhängi=
g.


http://dev.mysql.com/doc/refman/4.1/en/numeric-types.html
http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html
http://dev.mysql.com/doc/refman/6.0/en/numeric-types.html

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:

> Christoph Herrmann schrieb:
>
>> für die Validierung von Zahlen vor der Speicherung in einer MySQL
>> Datenbank müsste ich prüfen, ob diese in dem Wertebereich der jeweiligen
>> Datentypen liegen (Integer, Bigint, Double). [...]
>
> http://dev.mysql.com/doc/refman/4.1/en/numeric-types.html
> http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html
> http://dev.mysql.com/doc/refman/6.0/en/numeric-types.html

Und für DOUBLE?

Gruß. Claus

Claus Reibenstein schrieb:

> Und für DOUBLE?

DOUBLE ist AFAIK inzwischen ein Synonym für FLOAT.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:

> Claus Reibenstein schrieb:
>
>> Und für DOUBLE?
>
> DOUBLE ist AFAIK inzwischen ein Synonym für FLOAT.

Das beantwortet meine Frage nicht, denn FLOAT ist ebenfalls kein
ganzzahliger Datentyp.

Gruß. Claus

Claus Reibenstein schrieb:
> Niels Braczek schrieb:
>
>> Claus Reibenstein schrieb:
>>
>>> Und für DOUBLE?
>>
>> DOUBLE ist AFAIK inzwischen ein Synonym für FLOAT.
>
> Das beantwortet meine Frage nicht, denn FLOAT ist ebenfalls kein
> ganzzahliger Datentyp.

Die Seiten, die ich nannte, enthalten neben der Tabelle auch Text.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:

> Claus Reibenstein schrieb:
>
>> Niels Braczek schrieb:
>>
>>> Claus Reibenstein schrieb:
>>>
>>>> Und für DOUBLE?
>>>
>>> DOUBLE ist AFAIK inzwischen ein Synonym für FLOAT.
>>
>> Das beantwortet meine Frage nicht, denn FLOAT ist ebenfalls kein
>> ganzzahliger Datentyp.
>
> Die Seiten, die ich nannte, enthalten neben der Tabelle auch Text.

Richtig. Aber auch da finde ich keine konkreten Angaben zum Wertebereich
dieser Typen.

Gruß. Claus

Claus Reibenstein schrieb:
> Niels Braczek schrieb:

>> Die Seiten, die ich nannte, enthalten neben der Tabelle auch Text.
>
> Richtig. Aber auch da finde ich keine konkreten Angaben zum Wertebereic=
h
> dieser Typen.

Es ist sehr wahrscheinlich, dass die interne darstellung IEEE 754 folgt.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:

> Claus Reibenstein schrieb:
>
>> Niels Braczek schrieb:
>>
>>> Die Seiten, die ich nannte, enthalten neben der Tabelle auch Text.
>>
>> Richtig. Aber auch da finde ich keine konkreten Angaben zum Wertebereich
>> dieser Typen.
>
> Es ist sehr wahrscheinlich, dass die interne darstellung IEEE 754 folgt.

Mit Vermutungen ist niemandem geholfen.

Entweder Du weißt definitiv, dass IEEE 754 benutzt wird, und kannst es
auch belegen, oder Du lässt solche unqualifizierten Äußerungen sein.

Gruß. Claus

Claus Reibenstein meinte:
> Niels Braczek schrieb:
>> Es ist sehr wahrscheinlich, dass die interne darstellung IEEE 754 folgt.

> Mit Vermutungen ist niemandem geholfen.
>
> Entweder Du weißt definitiv, dass IEEE 754 benutzt wird, und kannst es
> auch belegen, oder Du lässt solche unqualifizierten Äußerungen sein.

Was soll das Geraunze? Steht eh in der Doku.

http://dev.mysql.com/doc/refman/5.1/de/numeric-type-overview .html

Also: Das BS bzw. die Hardware entscheidet in letzer Instanz.

Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Claus Reibenstein schrieb:
> Niels Braczek schrieb:

>> Es ist sehr wahrscheinlich, dass die interne darstellung IEEE 754 folg=
t.
>
> Mit Vermutungen ist niemandem geholfen.

Dir vielleicht nicht. Dem OP hat das möglicherweise bei der Suche
weitergeholfen.

> Entweder Du weißt definitiv, dass IEEE 754 benutzt wird, und kannst e=
s
> auch belegen, oder Du lässt solche unqualifizierten =C4ußerungen se=
in.

Was bitte war an meiner Aussage unqualifiziert? Du solltest vielleicht
mal deine Haltung bzw. deinen Tonfall überdenken.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:
> Claus Reibenstein schrieb:
>> Niels Braczek schrieb:
>
>>> Es ist sehr wahrscheinlich, dass die interne darstellung IEEE 754 folgt.
>> Mit Vermutungen ist niemandem geholfen.
>
> Dir vielleicht nicht. Dem OP hat das möglicherweise bei der Suche
> weitergeholfen.

selbst wenn ich wüsste was IEEE 754 ist hilft mir ein "wahrscheinlich"
echt nicht weiter. :) Da es bei mir um die Datenvalidierung geht und die
Vermeidung von Fehlern ist mir eine konkrete Aussage schon wichtig.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Gregor Kofler schrieb:
> Was soll das Geraunze? Steht eh in der Doku.
>
> http://dev.mysql.com/doc/refman/5.1/de/numeric-type-overview .html
>
> Also: Das BS bzw. die Hardware entscheidet in letzer Instanz.

und wie soll man dann am besten den Wertebereich abfragen? Einfach in
die Datenbank speichern und Fehler abfangen ist zwar eine Option, aber
keine wirklich schöne wie ich finde.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Niels Braczek schrieb:
>> Claus Reibenstein schrieb:
>>> Niels Braczek schrieb:
>>
>>>> Es ist sehr wahrscheinlich, dass die interne darstellung IEEE 754 fo=
lgt.
>>> Mit Vermutungen ist niemandem geholfen.
>>
>> Dir vielleicht nicht. Dem OP hat das möglicherweise bei der Suche
>> weitergeholfen.
>
> selbst wenn ich wüsste was IEEE 754 ist hilft mir ein "wahrscheinlich=
"
> echt nicht weiter. :) Da es bei mir um die Datenvalidierung geht und di=
e
> Vermeidung von Fehlern ist mir eine konkrete Aussage schon wichtig.

Man könnte ja den Begriff mal in die Suche bei MySQL eingeben. Unter
anderem kommt als Ergebnis die Seite
http://dev.mysql.com/doc/refman/4.1/en/myisam-storage-engine .html, in
der folgender Absatz steht:

"All data values are stored with the low byte first. This makes the data
machine and operating system independent. The only requirements for
binary portability are that the machine uses two's-complement signed
integers and IEEE floating-point format. These requirements are widely
used among mainstream machines. Binary compatibility might not be
applicable to embedded systems, which sometimes have peculiar processors.=
"

Damit ist meine Vermutung bestätigt und du hast deine konkrete Aussage.=


MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Christoph Herrmann schrieb:
> Harald Stowasser schrieb:
>> Die wichtigere Frage ist wohl eher mit welcher *Genauigkeit* du die Zahl
>> speichern möchtest.
>
> Im Prinzip so genau wie möglich.

Diese aussage ist _sehr_ unqualitativ. Du solltest schon wissen was du
brauchst, und was nicht!
Wenn du exakte Mathematik wie z.B. in der Kryptografie benötigst ist das
Schlüsselwort BigInteger[1]

mit toBytes( ) kannst du dann das ganze als Blob oder String in die DB
Klatschen.

Willst du auch noch mit Nachkommastellen rechnen musst du entweder die
Klasse mit Festkomma Arithmetik erweitern, oder eine Implementation zu
BigDecimal suchen/selber schreiben. Ich hab auf die schnelle leider
keine für PHP gefunden :-(

> Allerdings wenn der Wertebereich
> schwankt ist mir Sicherheit wichtiger, weswegen ich dann den
> kleinstmöglichen Wertebereich bevorzugen würde, der auf jeden Fall zu
> speichern geht (Es soll vor allem SQL Fehlern vorgebeugt werden).

Kleinstmöglichen Wertebereich = Bool?

> Muss doch eine einfache Möglichkeit geben zu überprüfen ob eine Zahl im
> Wertebereich des Datentypes der Datenbank liegt.

Ja. Die Frage ist nur Was ist für dich eine Zahl?

Für die einen ist PI eine Zahl. Für die andren ist es die längste Pra^W
Verkettung von Ziffern der Welt. Für manche ist es ein Dubble. Für
Querulanten ist es ein String. Für wiederum andere ist PI einfach nur
4*Ak/Aq. Und coole coderz machen nur "imul ax,25;asr eax,3;".

> Oder bin ich der
> einzige der sowas braucht? :)

Ja.
Vielleicht erläuterst du mal genau wozu du unterschiedliche Datentypen
benötigst. Mir drängt sich der Verdacht auf, das du schon im
Anwendung-Design Fehler machst.


[1]http://pear.php.net/package/Math_BigInteger/docs/latest/M ath_BigInteger/Math_BigInteger.html

Harald Stowasser schrieb:
> Kleinstmöglichen Wertebereich = Bool?

Kleinstmöglicher Wertebereich im Bezug auf die Datentypen der Datenbank.
Also ich brauch einen Wertebereich für Integer (den haben wir ja schon
gefunden), Bigint (glaub den haben wir auch bei den geposteten Links)
und Double (der kann variieren) der auf jeden Fall in diesen Datentyp
gespeichert werden kann um dies VOR der eigentlichen Speicherung in die
Datenbank abprüfen zu können.

> Ja. Die Frage ist nur Was ist für dich eine Zahl?

eine Abfolge von Ziffern.

> Ja.
> Vielleicht erläuterst du mal genau wozu du unterschiedliche Datentypen
> benötigst. Mir drängt sich der Verdacht auf, das du schon im
> Anwendung-Design Fehler machst.

Daten kommen über Formular rein, werden geprüft und bei Gültigkeit
weiterverarbeitet (zum Beispiel in die Datenbank geschrieben). Ist bei
der Prüfung eine Variable ungültig wird das Formular nicht verarbeitet
und der Benutzer bekommt eine Meldung, was er verbessern muss.

Um nun die Zahlen zu prüfen, die in die Datenbank kommen sollen, brauch
ich Prüfungen die die übergebene Variable auf eine Zahl prüfen und auch
den Wertebereich, den die Zahl annehmen darf überprüfen. Somit kann ich
dann sagen, die Zahl ist als Bigint/Integer/Double gültig und kann auch
ohne Fehler in die Datenbank geschrieben werden. Ist eine Zahl nicht im
Wertebereich kann ich genau sagen, welche es war. Würde ich nur den SQL
Fehler abfangen könnt ich zwar sagen da war was falsch, aber nicht was.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Gregor Kofler schrieb:
>> Was soll das Geraunze? Steht eh in der Doku.
>>
>> http://dev.mysql.com/doc/refman/5.1/de/numeric-type-overview .html
>>
>> Also: Das BS bzw. die Hardware entscheidet in letzer Instanz.
>
> und wie soll man dann am besten den Wertebereich abfragen? Einfach in
> die Datenbank speichern und Fehler abfangen ist zwar eine Option, aber
> keine wirklich schöne wie ich finde.

Warum wehrst Du Dich so sehr gegen diese Option? MySQL ist so ziemlich
die einzige Instanz, die zuverlässig entscheiden kann, was sie kann und
was nicht. Also wäre es doch das Vernünftigste, ihr die Entscheidung zu
überlassen, anstatt vorher irgendwelche überflüssigen Prüfungen vorzunehmen.

Andererseits sollte eigentlich eher die _Anwendung_ den zulässigen
Wertebereich vorgeben und nicht die Datenbank. Die muss den Wertebereich
nur abdecken können, und da genügt idR schon die Wahl des richtigen
Datentyps. Wenn Du in Deiner Anwendung solche Vorgaben nicht machen
möchtest, dann gibt es dort auch nichts zu prüfen.

Gruß. Claus

Claus Reibenstein schrieb:
> Warum wehrst Du Dich so sehr gegen diese Option? MySQL ist so ziemlich
> die einzige Instanz, die zuverlässig entscheiden kann, was sie kann und
> was nicht. Also wäre es doch das Vernünftigste, ihr die Entscheidung zu
> überlassen, anstatt vorher irgendwelche überflüssigen Prüfungen vorzunehmen.

Wenn ich vorher prüfe kann ich aber genau sagen "Die Zahl im Feld a
besitzt nicht den gültigen Wertebereich von x bis y". Wenn ich nur auf
SQL Fehler prüfe kann ich an den Benutzer nur ausgeben "ging nicht,
mögliche Ursachen könnten ungültige Eingaben irgendwo sein".

Ich finde das schon ein Vorteil, wenn man es vorab prüfen könnte :)

> Andererseits sollte eigentlich eher die _Anwendung_ den zulässigen
> Wertebereich vorgeben und nicht die Datenbank. Die muss den Wertebereich
> nur abdecken können, und da genügt idR schon die Wahl des richtigen
> Datentyps. Wenn Du in Deiner Anwendung solche Vorgaben nicht machen
> möchtest, dann gibt es dort auch nichts zu prüfen.

Differenzierte Einschränkung des Wertebereiches ist optional. Falls es
nicht geht, den direkten Wertebereich des Datentypes abzufragen, werde
ich wohl aber auf diese Möglichkeit zurück greifen, daher man muss
selbst logische Grenzen festlegen was gültig ist.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:

> Claus Reibenstein schrieb:
>
>> Warum wehrst Du Dich so sehr gegen diese Option? MySQL ist so ziemlich
>> die einzige Instanz, die zuverlässig entscheiden kann, was sie kann und
>> was nicht. Also wäre es doch das Vernünftigste, ihr die Entscheidung zu
>> überlassen, anstatt vorher irgendwelche überflüssigen Prüfungen vorzunehmen.
>
> Wenn ich vorher prüfe kann ich aber genau sagen "Die Zahl im Feld a
> besitzt nicht den gültigen Wertebereich von x bis y". Wenn ich nur auf
> SQL Fehler prüfe kann ich an den Benutzer nur ausgeben "ging nicht,
> mögliche Ursachen könnten ungültige Eingaben irgendwo sein".

Auch da gibt es Möglichkeiten. Zum Beispiel könntest Du MySQL in solch
einem Fall die fraglichen Werte nochmal einzeln rüberreichen und so die
problematischen ermitteln.

Geht nicht gibt's nicht :-)

Gruß. Claus

Claus Reibenstein schrieb:
> Auch da gibt es Möglichkeiten. Zum Beispiel könntest Du MySQL in solch
> einem Fall die fraglichen Werte nochmal einzeln rüberreichen und so die
> problematischen ermitteln.
>
> Geht nicht gibt's nicht :-)

mmh kann ich schlecht zentral machen, da ich nach der Prüfung keine
Kontrolle mehr über die Daten hab wo diese hingelangen. Außerdem wäre
das doch arg hässlich. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Claus Reibenstein schrieb:
>> Auch da gibt es Möglichkeiten. Zum Beispiel könntest Du MySQL in solch
>> einem Fall die fraglichen Werte nochmal einzeln rüberreichen und so die
>> problematischen ermitteln.
>>
>> Geht nicht gibt's nicht :-)
>
> mmh kann ich schlecht zentral machen, da ich nach der Prüfung keine
> Kontrolle mehr über die Daten hab wo diese hingelangen.

Zum einen: Muss das Ganze denn unbedingt komplett dynamisch sein. Würde
es nicht ausreichen, so etwas einmal in einem Installationsskript zu
ermitteln und dann in eine Konfigurationsdatei zu schreiben?

Ausserdem steht noch die Frage offen, _was_ für Daten du reinschreiben
möchtest, d.h. was für eine Genauigkeit überhaupt Sinn macht!

Viele Grüße
Christoph

Christoph Bersch schrieb:
> Zum einen: Muss das Ganze denn unbedingt komplett dynamisch sein. Würde
> es nicht ausreichen, so etwas einmal in einem Installationsskript zu
> ermitteln und dann in eine Konfigurationsdatei zu schreiben?

Hardware ändert sich eher selten, von daher würde das theoretisch
ausreichen. Wobei ich lieber dazu tendiere es immer aktuell zu wissen
und nur pro Seitenaufruf cache.

> Ausserdem steht noch die Frage offen, _was_ für Daten du reinschreiben
> möchtest, d.h. was für eine Genauigkeit überhaupt Sinn macht!

im Prinzip könnte ich diese sogar angeben lassen (Anzahl Stellen und
davon Dezimalstellen) bei der Definition der Tabellen. Mit den Angaben
wäre eine Prüfung dann auch einfacher. Ist mir gerade so aufgefallen wie
ich die Datentypbeschreibung von MySQL durchgelesen hab. Da ich die
Tabelleninformationen eh im System habe, kann ich auf diese jederzeit
zugreifen.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:

> Daten kommen über Formular rein, werden geprüft und bei Gültigkeit
> weiterverarbeitet (zum Beispiel in die Datenbank geschrieben). Ist
> bei der Prüfung eine Variable ungültig wird das Formular nicht
> verarbeitet und der Benutzer bekommt eine Meldung, was er verbessern
> muss.

Dann suchst du http://pecl.php.net/package/filter

> Um nun die Zahlen zu prüfen, die in die Datenbank kommen sollen,
> brauch ich Prüfungen die die übergebene Variable auf eine Zahl prüfen
> und auch den Wertebereich, den die Zahl annehmen darf überprüfen.
> Somit kann ich dann sagen, die Zahl ist als Bigint/Integer/Double
> gültig und kann auch ohne Fehler in die Datenbank geschrieben werden.
> Ist eine Zahl nicht im Wertebereich kann ich genau sagen, welche es
> war. Würde ich nur den SQL Fehler abfangen könnt ich zwar sagen da
> war was falsch, aber nicht was.

Du willst die Filter also automatisieren? Das würde ich nicht machen, da
sich normalerweise das DB-Design nicht ändert. Aber bitte:

<ungetestet>
$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
foreach ($dbh->query('DESC FOO') as $row) {
if (filter_has_var(INPUT_POST,$row[0]))){
$leng=0;
$typ=$row[1]
if ( strpos( $typ, '(' ) !== false ) {
$leng = intval(substr( $col[1], strpos( $col[1], '(' ) + 1,
strpos( $typ, ')' ) ) );
}
if ( strpos( $typ, 'decimal' ) !== false ) {
filter_input ( INPUT_POST, $row[0],
FILTER_VALIDATE_REGEXP,'[0-9,]')
} elseif ( strpos( $typ, 'char' ) !== false ) {
filter_input ( INPUT_POST, $row[0],FILTER_SANITIZE_STRING);
} elseif ( strpos( $typ, 'text' ) !== false ) {
filter_input ( INPUT_POST, $row[0],FILTER_SANITIZE_STRING);
} elseif ( strpos( $typ, 'int' ) !== false ) {
if (!filter_input ( INPUT_POST, $row[0],FILTER_VALIDATE_INT)){
echo $row[0].'idt Flasch';
}
}

....
}
}
</ungetestet>

oder so ähnlich.
Normalerweise weiß der Programmierer einer Applikation welche Werte
*Sinn* machen. Diese Werden werden dann Validiert oder ggf gereinigt.
Die automatische Prüfung wie Oben erzeugt nur Overhead.

Christoph Herrmann schrieb:
> Christoph Bersch schrieb:
>> Ausserdem steht noch die Frage offen, _was_ für Daten du reinschreiben
>> möchtest, d.h. was für eine Genauigkeit überhaupt Sinn macht!
>
> im Prinzip könnte ich diese sogar angeben lassen (Anzahl Stellen und
> davon Dezimalstellen) bei der Definition der Tabellen.

Hm, _woher_ kommen dann jetzt diese Zahlen? Sind das Ergebnisse von
numerischen Rechungen, Auswertungen, Messwerte, ist es pi mit 1000
Stellen, oder was?

Viele Grüße
Christoph

Christoph Bersch schrieb:
> Hm, _woher_ kommen dann jetzt diese Zahlen? Sind das Ergebnisse von
> numerischen Rechungen, Auswertungen, Messwerte, ist es pi mit 1000
> Stellen, oder was?

Aus meiner Applikation. ;) Der Aufbau der Tabellen wird mit PHP selbst
innerhalb der Applikation gemacht. Aus dem Grunde kann ich zu jeder Zeit
abfragen, welchen Datentyp eine Spalte in der Tabelle hat indem ich in
dieser Definition nachschaue. Und wenn ich hier die Anzahl der Ziffern
($number) und die Anzahl der Nachkommastellen ($scale) hinterlege kann
ich mit folgender Rechnung den höchsten darstellbaren Wert ermitteln:

bei unsigned zum Beispiel:
0 - pow(10, $number - $scale) - pow(10, $scale * -1)

(natürlich muss $number größer sein als $scale)

würde bei 5 Stellen und davon 2 Nachkommastellen 1000 - 0,01 ergeben und
somit die größtmögliche Zahl 999,99 (wenn ich richtig erdacht habe).

PS: Gerade weil ich weiß welcher Datentyp eine Spalte hat, brauch ich
dieses, weil ich eine Factory Klasse hab für Formularelemente bei der
ich einfach Tabellenname und Spaltenname übergebe und die Factory mir
das Element gibt, was zu der Spalte gibt inklusive dem Validator der die
übergebenen Werte überprüft. (Natürlich nur bedingt, wenn ich eine
Auswahlliste haben will geht das nicht, weil Zeichenfelder immer als
Textfield bzw. Textarea zurück gegeben werden).

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Christoph Bersch schrieb:
>> Hm, _woher_ kommen dann jetzt diese Zahlen? Sind das Ergebnisse von
>> numerischen Rechungen, Auswertungen, Messwerte, ist es pi mit 1000
>> Stellen, oder was?
>
> Aus meiner Applikation. ;) Der Aufbau der Tabellen wird mit PHP selbst
> innerhalb der Applikation gemacht. Aus dem Grunde kann ich zu jeder Zeit
> abfragen, welchen Datentyp eine Spalte in der Tabelle hat indem ich in
> dieser Definition nachschaue. Und wenn ich hier die Anzahl der Ziffern

Bzw. sind diese Daten für bestehende Tabellen mit Sicherheit auch
nachträglich abrufbar in MySQL.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Bei dem Topic habe ich sofort an

echo '<span style=3D"font-size:800px;">123</span>';

als Lösung gedacht...


*SCNR*

OLLi

Oliver Grätz schrieb:

> Bei dem Topic habe ich sofort an
>
> echo '<span style="font-size:800px;">123</span>';
>
> als Lösung gedacht...

Deutse Sprak swere Sprak?

"Darstellung sehr großer Zahlen" und "Sehr große Darstellung von Zahlen"
sind zwei vollkommen verschiedene Dinge.

Wer lesen kann, ist eben doch im Vorteil ;-)

> *SCNR*

Dito. Claus

Claus Reibenstein schrieb:
>> Bei dem Topic habe ich sofort an
>>
>> echo '<span style=3D"font-size:800px;">123</span>';
>>
>> als Lösung gedacht...
>
> Deutse Sprak swere Sprak?
>
> "Darstellung sehr großer Zahlen" und "Sehr große Darstellung von Za=
hlen"
> sind zwei vollkommen verschiedene Dinge.

Neee, ich habe das eher als Zahlenvariante von "Hey ich will die
Buchstaben vom Hollywoodschild auf meiner Webseite darstellen. Wisst ihr
wie ich das mache?" verstanden. Als durchaus "sehr große Zahlen", so wi=
e
in "acht Meter groß" und man will sie angemessen darstellen. *g*

Ich hoffe du kennst den Post "Wie kann ich denn das aktuelle Wetter
ausgeben?" mit der Antwort "print('Es regnet.');". Wieso wird eigentlich
best of dclp.misc auf develnet nicht mehr gepflegt?

OLLi

--
Frage: "Nennen sie mindestens drei Aggregatszustände."
Antwort: "An, Aus, Kapput."

Oliver Grätz schrieb:

> Wieso wird eigentlich best of dclp.misc auf develnet nicht mehr gepflegt?

Wahrscheinlich weil Daniel hier nicht mehr mitliest. Vielleicht sollte
man sowas mal wieder aufbauen. Allerdings fände ich da eine Lösung für
die FAQ erstmal wichtiger.

--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)