MySQL Einträge ändern

[ralli]

@Christian, das hatte ich @pjensen auch schon empfohlen, aber er will sich partou mehr Arbeit machen... Mit dbmaker kann ich auch schon Angebote schreiben und mit Lazreport designen und ausdrucken, das geht alles ohne grossen Aufwand. Denn für einige Aufgaben ist ein Datenbankserver doch überdimensioniert, denn da würde man mit Kanonen auf Spatzen schiessen. Im übrigen gibt es auch noch für dateibasierte lolake Datenbanken die Komponente TMemDataSet, wem das dbf Format nicht zusagt. Da habe ich unter Delphi bereit eine fertige Anwendung memmaker geschrieben. Vielleicht lohnt es, die auch mal zu portieren. Wenn die nicht dem Löschwahn zum Opfer gefallen ist, denn ich verwahre nicht alles auf.

ralli

[ralli]

Und noch eins ist nicht unwichtig. Firebird kann ich bedenkenlos auch kommerziell einsetzen, ohne dafür Lizenzkosten berappen zu müssen. Und die Komponenten flib und uib sind sehr ausgereift, es gibt wirklich gute Beispiele und wenn ich mir das Installations Wiki von Zeos anschaue, dann lass ich da erst mal die Finger von, bis es den Mindeststandards genügt. Jetzt werde ich erst mal meinen angefangenen fbmaker für firebird fertig stellen und dann sehen wir weiter. Firebird lässt sich problemlos installlieren, läuft absolut stabil ist sehr gut auch in deutsch dokumentiert und kann natürlich in Produktivumgebungen eingesetzt werden. Und zu guter letzt ist firebird wirklich völlig kostenlos. Deshalb ist firebird auch für mich erste Wahl. Zumindest bei Anwendungen auf dem PC. Im Web bevorzuge ich auch mysql, weil firebird wohl auch von den Providern nicht unterstützt wird. Und was mir nicht gefällt, mysql war nicht zuletzt so affenschnell, weil es sich auf die wichtigsten Funktionen beschränkte. Zur Zeit wird es von mysql AB so aufgebohrt, das es auch zur eierlegenden Wollmilchsau mutierte. Aber will ich das ? Vielleicht brauchen das nur 10 % der Benutzer. Wenn überhaupt. Alle, die jetzt überlegen, sich mal mit firebird zu beschäftigen, bitte nicht den Classic Server installieren, der läuft garantiert nicht, sondern immer den firebird Superserver nehmen. Der läuft einwandfrei in der Version 1.5 x und 2.0x. Und noch eins, ich arbeite und programmier nun seit über 20 Jahren mit relationalen Datenbanken, habe mich erfolgreich mit Datenbankservern auseinandergesetzt. Das Problem ist oft das Gleiche, die Benutzer kennen Ihr Anforderungsprofil zu wenig, und richten sich dann nach dem, was sie von anderen mal gehört haben. Meisten setzen sie dann ein Datenbanksystem ein, was völlig überdimensioniert ist. Und wechseln von einem Sql System auf ein anderes mit der dazugehörigen Migration, dürdfte heute auch kein Problem mehr darstellen. Weil der Grundvorrat an SQL Befehlen ja auch sowieso standardisiert ist. Und Oracle dürfte wohl von der Ivestitionsseite für niemanden ernsthaft in Frage kommen. Ansonsten ist der Markt für Datenbanken erheblich geschrumpft und eher übersichtlich...

ralli

[af0815]

Das Problem ist oft das Gleiche, die Benutzer kennen Ihr Anforderungsprofil zu wenig, und richten sich dann nach dem, was sie von anderen mal gehört haben. Meisten setzen sie dann ein Datenbanksystem ein, was völlig überdimensioniert ist. Und wechseln von einem Sql System auf ein anderes mit der dazugehörigen Migration, dürdfte heute auch kein Problem mehr darstellen. Weil der Grundvorrat an SQL Befehlen ja auch sowieso standardisiert ist. Und Oracle dürfte wohl von der Ivestitionsseite für niemanden ernsthaft in Frage kommen. Ansonsten ist der Markt für Datenbanken erheblich geschrumpft und eher übersichtlich...
ralli

Das eher Philisophische daran ist, das es leider immer wieder vorkommt, da Leute gute Programme auf Desktopdatenbanken (DBase, Access,...) entwickelt haben und dann diese Anwendungen auf einen Server portieren. Und dann gehts am Anfang gut, bis die Datenmengen größer werden und dann herumgebastelt wird, damit das halbwegs funktioniert. Auch bei Schulabgänmgern und Proktikanten beobachtet. Keiner hat bei seinen kleinen Projekten sich je mit Datenmengen auseinandergesetzt. Und wunder sich, wenn bei einem 'Sel_ect * from table' plötzlich 200.000 Datensätze kommen und das ganze 1 Minute dauert

Desktop Datenbanken sind gut und performant wenn richtig eingesetzt, aber man darf beim Design nicht wirklich aus den Augen verlieren, was kann als Datenmenge kommen und vor allen wie funktioniert die Wartung/Backup. Das Kapitel wird von den meisten gar nicht berücksichtigt.
Beispiel eine BDE Erfassung bei einem Schnellläufer (Maschine mit hohen Output) kann schon mal 100.000 bis 1.000.000 Buchungen am Tag bedeuten. Die täglich verdichtet werden. Da wird ein bereinigen der obsoleten Datensätze, ein Kompress im laufen, Auswertungen etc. zur Herausforderung und sogar 'poor Man' Server können da schon schnell in die Knie gehen, von Desktopdatenbanken ganz zu schweigen.
Das Problem ist, es macht sich keiner die Mühe, in seine Datenbank soviele Datensätze einzufüllen, das er in die Nähe der Projektierten Grenze kommt. Und wenn es 1000 Datensätz bei einer einfachen Adressverwaltung sind. Da kann es dann ganz schöne 'AHA' Erlebnisse geben. Gar nicht zu reden wenn es auf mehreren Arbeitsplätzen zugleich laufen soll.

Deshalb meine Meinung, man sollte das Design entsprechend auslegen, dort auch die Entwicklung hineinlegen (auch bei kleinen Projekten) denn dann ist die halbe Arbeit getan und der Rest ist Tippsen und Optik

[Christian]

Verliert ihr gerad die Frage aus den Augen ?

[ralli]

@af0815, da stimme ich Dir voll und ganz zu, die zu erwartende Datenmenge plus Puffer sind ein sehr wichtiges Entscheidungskriterium, vielleicht das WICHTIGSTE. Obwohl bei einem Freiberufler ja eher nicht solche Datenmengen anfallen.

Also zum Test habe ich in (fast allen Datenbankformaten) kleinere Datenbestände mehrerer Städte mit Telefonbucheinträgen bis zu der Stadt Hamburg, die ca 700000 Datensätze umfasst. Es ist erstaunlich, das ich auch bei meinem dbmaker mit der tdbf Komponente bei einer normalen Abfrage zu einer erträglichen Antwortzeit kommt.

ralli

[af0815]

@Christian
Sei vorsichtig mit dem Steinewerfen. Immerhin geht es noch immer um Datenbanken. Und imentfernsten um Design MySQL oder ähnlich.

@ralli
Ich mache eine neue Diskussion auf.
> Grundlegendes Datenbankdesign

[Christian]

Ich werfe gar keine Steine, in der Frage ging es lediglich um <10 datensätze soweit ich das verstanden habe und ihr fangt hier mit Grundsatzdiskussionen zu DBS an ?!

[pjensen]

Dank Eurer Hilfe ist ein großer Teil meines Programms fertig.
Dafür erstmal vielen Dank!!

Jetzt kommt das Filtern der Einträge mit mysql.

Darf man in diesem Forum auch Fragen zu MySQL stellen ?

Z.B. ('S_ELECT * FROM clients WHERE Ort LIKE "%burg%"') funktioniert, ich will aber in allen Spalten %burg% suchen können.

ODER: Welche Kollation empfeht Ihr (teilweise funktionieren die Umlaute bei mir nicht).?

[Christian]

S_ELECT * FROM clients WHERE * LIKE "%burg%"' geht nicht ?

[af0815]

Z.B. ('S_ELECT * FROM clients WHERE Ort LIKE "%burg%"') funktioniert, ich will aber in allen Spalten %burg% suchen können.

Du wirst mit 'OR' und der Aufzählung leben müssen.

'S_ELECT Ort, Strasse, Adresse, PLZ FROM clients WHERE (Ort LIKE "%burg%") OR (Strasse LIKE "%burg%") ....'

eventuell nicht direkt den Text im SQL-Statement angeben sondern Parameter verwenden. Somit brauchst Du nur den Parameter ändern und mußt nicht das ganze Statement neu erzeugen.

Es gubt natürlich auch die Möglichkeit, das Statement mehrmals abzusetzen und die Ergebnisse mit UNION zu verknüpfen (UNION SE_LECT).

[pjensen]

@: Christian: Nein, das geht nicht.
@: af0815: Das geht, einfach aus 17 Spalten eine Query zusammen gebastelt,
Danke :)


Frage:

Ich habe aus einer OpenOffice Tabelle ca. 3000 Zeilen "echte" Daten exportiert. Hierbei sind viele Wörter mit Umlauten. Diese habe ich als utf-8 exportiert in eine csv-datei. Diese csv-Datei habe ich mit pypmyadmin in die Tabelle geschrieben. Kollation ist hierb utf-8.

Im Grid werden die Wörter angezeigt, jedoch fehlen die Umlaute.
Also: Müller => Mller.

Im dazugehörigen DBEdit wird nichts angezeigt, wenn ein Umlaut im Wort vorkommt.

Wenn ich im Grid oder im dazugehörigen DBEdit einfach "Müller" reinschreibe, funktioniert es hinterher. Ich kann es wunderbar sehen, auch mit Umlaut.

Wenn ich anschließend mit phpmyadmin in die Daten gucke, steht bei Müller Hyroglyphenzeuchs drin , wo das ü sein müßte,

Oder anders gefragt:
Ich kann bei OpenOffice mit diversen Zeichensätzen als csv abspeichern.
Ich kann mit phpmyadmin diverse Kollationen einstellen.

Was empfehlt Ihr oder was ist üblich für die Deutsche Sprache?
Notfalls könnte ich auch mit OO vorher mit Suchen + Erstztn die Umlaute rausfiltern...



Verständnisfrage;
Bei mir ist er mysql-Server ein anderer PC im 100Mb-Lan.

Beim Programmstart werden die Daten ins Grid eingelesen.
Der Aufbau der Daten 20 Spalten und 3000 Zeilen geht erschreckend schnell.
(Fast alles Varchar, 20 oder 50 Zeichen)

Wiese kann ich eigentlich über ein LAN-Netzwerk mit lächerlichen 100Mb so dermaßen schnell die Daten einlesen. Ich hätte erwartet, daß der Bildaufbau schon etwas Zeit braucht, weil die Daten erstmal durchs Kabel müssen.

Auch er Aufbau des o.g. Query , der 17 Spalten durchsucht geht so schnell, daß man das Ergebis ohne spürbare Zeitverzögerung bekommt.

Sind alle Daten im lokalen Rechner im Ram gecached und werden hier gefiltert, oder wie läuft das?

[af0815]

Verständnisfrage;
Bei mir ist er mysql-Server ein anderer PC im 100Mb-Lan.

Beim Programmstart werden die Daten ins Grid eingelesen.
Der Aufbau der Daten 20 Spalten und 3000 Zeilen geht erschreckend schnell.
(Fast alles Varchar, 20 oder 50 Zeichen)

Wiese kann ich eigentlich über ein LAN-Netzwerk mit lächerlichen 100Mb so dermaßen schnell die Daten einlesen. Ich hätte erwartet, daß der Bildaufbau schon etwas Zeit braucht, weil die Daten erstmal durchs Kabel müssen.

Auch er Aufbau des o.g. Query , der 17 Spalten durchsucht geht so schnell, daß man das Ergebis ohne spürbare Zeitverzögerung bekommt.

Sind alle Daten im lokalen Rechner im Ram gecached und werden hier gefiltert, oder wie läuft das?

Der Vorteil bei Serverbetrieb ist, das du auf Datenbanken optimierte Maschine hast. Wenn du das SQL Statement entsprechnd machst (und auch das Design passt), so kann der Server optimal arbeiten und du bekommst NUR das Result zurück. Wenn das nur eine Handvoll Daten sind (und das solltes so sein) geht das auch über das Netzwerk schnell.

Zum Server -> SQL Statement (sollte in 1 TCP/IP Paket passen).
Vom Server <- 10 Datensätze (sollten auch in 1-2 TCP/IP Pakete passen).

Deshalb geht es schnell, auch im Netz.

[pjensen]

@af0815

Aha.
Gibt der server mir eigentlich immer nur die Zeilen, die ich im Grid sehe, oder gibt er mir alle Zeilen?

Oder anders: Ich habe wesentlich mehr Zeilen als das Grid anzeigen kann. Werden Daten beim Scrollen vom Server zum Client geschoben oder kommen diese bei der Abfrage S_elect * from... komplett an?

By the way: Welche Kollation empfiehltst Du?

[af0815]

Aha.
Gibt der server mir eigentlich immer nur die Zeilen, die ich im Grid sehe, oder gibt er mir alle Zeilen?

Oder anders: Ich habe wesentlich mehr Zeilen als das Grid anzeigen kann. Werden Daten beim Scrollen vom Server zum Client geschoben oder kommen diese bei der Abfrage S_elect * from... komplett an?

Er macht normalerweise einen Ftech der nötigen Zeilen beim Server und nicht von allen, das hängen aber davon ab, wie es in der Komponente implementiert wurde und der Server kann. Denn nicht alle Features sind in allen DBs vorhanden.

By the way: Welche Kollation empfiehltst Du?

Kann ich dir nicht sagen, ich habe michda zuwenig mit MySQL beschäftigt.

Dein Problem dürften aber nicht zu 100% vom Server kommen. Denn Im Grid arbeiten kannst Du ja mit Umlauten. Somit gehts ja. Wenn Müll in anderen Applikationen angezeigt wird, so liegt es dort an dem Zeichensatz bzw. Implementierung.

Bezüglich PHPMyAdmin, so würde ich dort mal stöbern bzw. bei PHP.

[Christian]

Wie schon so oft gesagt, GTK1 ist nicht Unicodefähig.