Wie bekomme ich die CREATE-Befehle in eine Tabelle

Moin moin

Das wäre wirklich wichtig : Ich habe mich mit den verschiedenen
Zeichensätzen noch nicht sehr intensiv befasst. Wozu werden 30
verschiedene Zeichensätze unterstützt? Wenn mit utf-32 alles
erschlagen werden könnte?

weil es erst ASCII gab , und dann jedes land mal seine eigene sprache .
und erst viel später kam utf um alles zusammen zu fassen. und ja utf-8 macht alles neu , ist aber auch ein höherer aufwand. nicht jedes system muss extra utf tabellen etc haben , da reichen auch ascii bei dem normalen automaten etc.

Wenn man also gleich auf utf anfängt hat man auch keine probleme.
Und utf ist nicht text datei standard , deswegen ist es auch nicht das einzige was es gibt. Viel wird einfach mit ASCII erledigt oder der jeweiligen sprache. Das spart auch platz . Aber platz ist heute nicht ausschlaggebend . Auch wird bei einem 64bit rechner sich kein unterschied finden bei nur 4 bytes oder 2 bytes . der buss wird eh voll addressiert. :smile:

Hi,

würde utf8 auch für chinesisch und hebräisch reichen?

was mach ich mit der Sortierfolge (collation)?

Hallo FraLang,

Welche Sortierfolge ( Collation ) gibst du dann an?

Das mit der Collation ist tatsächlich das Problem dabei, denn wie willst Du russische, chinesische und lateinische Zeichen innerhalb einer Tabelle sortieren? Da bleibt wirklich nur der kleinste gemeinsame Nenner, nämlich die Sortierung rein nach den UTF-Zeichenwerten übrig.
Aber das Problem ist kleiner als man denkt, weil man ja innerhalb einer Suchanfrage sicher nur eine Sprache erhält und die kann man dann entweder in einer temporären Tabelle mit der passenden Collation sortieren (geht wirklich schnell) oder Du bemühst etwas außerhalb von MySQL zum Sortieren. Irgendeine externe Anwendung brauchst Du ja sowieso, da Du wohl niemandem nackte MySQL-Ausgaben vorsetzen kannst.

Werden dann
alle Texte mit 4 Bytes dargestellt? Bläht das nicht die
Datenbank um fast einen Faktor 4 auf?

Naja, utf-32 habe ich einfach als das obere Extrem aufgeschrieben, weil Du bei Thomas irgendwo die Tauglichkeit von UTF-8 für japanisch angezweifelt hattest. Eigentlich stimme ich mit Thomas überein, daß UTF-8 wohl ausreichen sollte. Aber wenn nicht, Speicherplatz sollte in den heutigen Zeiten wohl nicht die knappe Ressource darstellen. Ansonsten hast Du natürlich recht, UTF-16 braucht mehr als UTF-8 und UTF-32 mehr als UTF16, aber ist das wirklich wichtig?

Wozu werden 30
verschiedene Zeichensätze unterstützt? Wenn mit utf-32 alles
erschlagen werden könnte?

Das hat ja Thomas Punkt nun schon beantwortet.

Das Konzept in diesem Projekt ist aber ein anderes. Es werden
nur die Daten aus Views auf Tabellen vom Server zum
Anwender-PC übertragen, dort werden die Formulare aufgebaut,
Verarbeitungen, Eingaben, und satzweise Rückübertragungen zum
Server durchgeführt. Velleicht hätte man das Konzept bereits
anders gestalten sollen.

Wer hat sich denn sowas ausgedacht? So ein Konzept legt einem ja tatsächlich viele Steine in den Weg. Eingaben und Anfragen können ja nur auf den Clients stattfinden, das ist klar. Aber Formulare und Verarbeitungen (welche auch immer)? Wenn ich das richtig verstanden habe, bedeutet das ja auch, daß auf jedem Anwender-PC die spezielle Software installiert und gewartet werden muss, also alles mehrfach. Ihr habt ja sicher nicht nur drei Kunden…

Viele Grüße
Marvin

Moin moin,

Hi,

würde utf8 auch für chinesisch und hebräisch reichen?

also das aneignen von wissen werd ich dir nicht abnehmen. Da musst du schon Papa Schlumpf fragen.

was mach ich mit der Sortierfolge (collation)?

Keine Ahnung was du damit machst. Ich hab UTF .
Ich überschreib die coallition wie ich sie brauche .
Using COLLATE in SQL Statements.
Ob das gut ist , gute frage :smile:
Bis her hats gereicht für meine Sortierungen.

Hallo Marvin,

Naja, utf-32 habe ich einfach als das obere Extrem
aufgeschrieben, weil Du bei Thomas irgendwo die Tauglichkeit
von UTF-8 für japanisch angezweifelt hattest.

Nicht angezweifelt, gefragt, ich blick wirklich noch nicht ganz durch. Ich denke, dass die sprachbezogenen Zeichensätze großteils mit 8-bit-codes auskommen. Die Isonorm für hebräische Zeichen benutzt die Werte von xA0 bis xBE, wenn das dem Zeichensatz dann entspricht, stelle ich mit vor, kann man fast alles in 8 Bit darstellen. Der Kunde wird danach fragen. Die Tabellen können schon sehr groß werden und man mus auch die Überttragungszeit zum Anwender.PC berücksichtigen.

Das Konzept in diesem Projekt ist aber ein anderes. Es werden
nur die Daten aus Views auf Tabellen vom Server zum
Anwender-PC übertragen, dort werden die Formulare aufgebaut,
Verarbeitungen, Eingaben, und satzweise Rückübertragungen zum
Server durchgeführt. Velleicht hätte man das Konzept bereits
anders gestalten sollen.

Wer hat sich denn sowas ausgedacht? So ein Konzept legt einem
ja tatsächlich viele Steine in den Weg. Eingaben und Anfragen
können ja nur auf den Clients stattfinden, das ist klar. Aber

Ich habe mir dazu keine Gedanken mehr gemacht, da ich erst dazukam als das Projekt schon 1 Jahr lang in Entwicklung war. Aber ich find es eigentlich nicht so schlecht. Wir entwickeln in VB mit Visualstudio und Krypton Tools, das bietet so alles was man für das Benutzer-Interface benötigt. Auf seiten des Servers suchen sich stored procedures die Daten zusammen und übertragen sie an eine data table auf dem User-PC. Dort werden sie in einem MDI-System (Multi Document Interface) dem User zur Bearbeitung angeboten und geänderte Werte werden schließlich wieder zum an entsprechende stored procedures zurückübertragen. Es würde mich total interessieren, was man an diesem Konzept in welcher Form anders machen hätte können. Was würde sich ändern, wenn man php engesetzt hätte? Wäre es noch möglich, zwischen den stored procedures und dem Abschicken der Daten php zu setzen?

Anwender-PC die spezielle Software installiert und gewartet
werden muss, also alles mehrfach. Ihr habt ja sicher nicht nur
drei Kunden…

Sollte kein Problem sein, man muss nur die Installationsroutine so einfach gestalten, dass jeder auch unbefangene User es selber aufrufen kann.

Viele Grüße,
Franz

Hallo Thomas,

also das aneignen von wissen werd ich dir nicht abnehmen.

Schade.

Ich überschreib die coallition wie ich sie brauche .
Using COLLATE in SQL Statements.

Das ist allerdings schon eine Idee. Ich könnte die Collation auf irgendeinen Standard setzen und nur dort wo sie gebraucht wird expizit setzen. Bliebe nur mehr die Frage zu den Zeichensätzen.

Gr. F.

Hallo Franz,

Ich denke, dass die sprachbezogenen Zeichensätze
großteils mit 8-bit-codes auskommen.

Das denke ich auch, aber letztendlich kommt es eben drauf an, welche Zeichensätze ihr braucht. Übrigens kannst Du dich hier ganz gut über die verschiedenen Zeichensätze orientieren:
http://www.unicode.org/versions/Unicode6.0.0/
http://www.unicode.org/charts/

Die Tabellen können schon sehr groß werden und man mus auch
die Überttragungszeit zum Anwender.PC berücksichtigen.

Naja, da kann ich mich nur wiederholen. Die Tabellen selbst können schon sehr groß werden, aber normalerweise überträgt man eben nicht die ganze Tabelle, sondern nur das Ergebnis einer Abfrage. Und sollte das Ergebnis zu umfangreich werden, dann eben nur stückchenweise und der Kunde blättert sich durch. Das ist schon mal eine Antwort zu deiner Frage weiter unten, was ich an eurem Konzept nicht so toll finde.

Auf seiten des
Servers suchen sich stored procedures die Daten zusammen und
übertragen sie an eine data table auf dem User-PC. Dort werden
sie in einem MDI-System (Multi Document Interface) dem User
zur Bearbeitung angeboten und geänderte Werte werden
schließlich wieder zum an entsprechende stored procedures
zurückübertragen.

Das klingt für mich nun doch sehr danach, als ob auf der Clientseite nicht soviel passiert. Aber ehrlich gesagt, führt das auch zu weit weg, weil ich sozusagen nur die Konturen erahnen kann und über die Einzelheiten nichts weiss. Nur wenn ich von dir immer wieder höre, daß dieses und jenes für die schwachen Clients nicht machbar sei, dann drängt sich für mich immer wieder der Gedanke auf, daß dann eben soviel wie möglich serverseitig passieren muß und so wenig wie möglich auf den Clients. Aber ich kann und will mich da nicht zu tief reinhängen

Was würde sich ändern, wenn man php engesetzt hätte? Wäre es
noch möglich, zwischen den stored procedures und dem
Abschicken der Daten php zu setzen?

Kann ich schwer was dazu sagen, weil ich Null Ahnung von eurer VB-Anwendung habe. Aber mit aller Vorsicht, ich denke schon, daß das ginge, warum auch nicht. Aber letztendlich sitze ich ja nicht in eurer Entwicklungsabteilung :wink: Ich will mich gar nicht auf PHP festlegen, ich bin lediglich von einem Webformular ausgegangen, das mit einer beliebigen serverseitigen Sprache befüllt wird und das Ganze dann eventuell noch mit Ajax aufgepeppt, um eine asynchrone Verarbeitung möglich zu machen (wenn nötig).

man muss nur die
Installationsroutine so einfach gestalten, dass jeder auch
unbefangene User es selber aufrufen kann.

Und genau das ist ein wichtiger Punkt für mein Unbehagen. User sollten so wenig wie möglich Software installieren müssen, und unbedarfte User am besten gar keine, weil sie sonst gerne noch ganz andere Sachen installieren, und das oft nicht mal wissen oder merken…
Aber wie gesagt, wir sind hier schon lange an einem Punkt, der weit über konkrete Tipps hinausgeht.

Viele Grüße
Marvin

also wenn da um übertragungs platzprobleme geht, das hatten alle spiele als es noch das 56k modem gibt und seid dem wird alles gepackt und wieder entpackt . Damit kriegt man auch noch mal eine reduktion hin.
damit wird bei utf bestimmt eine menge gesparrt denn viele bytes sind einfch nur Füllung :smile:

Ich denk mal das VB genommen wird weil noch einiges anders gemacht werden soll, was ein Browser wohl so nicht tut.

Aber hätte man , wenn es denn nur auf den Platz und Leistung ankommt , nicht gleich für jede sprache einen VIEW angeboten ? Dann hat der Server die Aufgabe schon erledigt und in der benötigten sprache vorliegen.

Ich würd aber wenn schon client da ist zum installieren, einfach ein wörterbuch als xml hinterlegen . Denn in der Programmiersprache selber ist es kein Zeitverlusst auch 200.000 wörtr zu übersetzen , auch wenn ich ncht glaub das jemand vor dem client wirklich 200.000 wörter gleichzeitig angugt.

Ich würd also die übersetzung dahin verlegen wo sie zu sein hat, nicht in die daten übertragung sondern in die ansicht und die ist beim user niemals 200.000 zeilen gleichzeitig .

Also ein index mit 200.000 wird quasi genausoschnell direkt zugegriffen wie beim index von 1000 . Ausser wenn millisekunden wichtig sind bei der anzeige.

Hab nochmal nachgeugt , ich arbeite mit utf-16 . Weil ich die funktionen für 16 hatte :smile:

Aber hier mal eine info dazu warum man utf hat braucht nutzt
http://toscho.de/2010/warum-utf-8/

Hallo Marvin,

man eben nicht die ganze Tabelle, sondern nur das Ergebnis
einer Abfrage. Und sollte das Ergebnis zu umfangreich werden,
dann eben nur stückchenweise und der Kunde blättert sich

Ja, das sehe ich auch so, ich werde versuchen soviel wie möglich in SQL-Prozeduren vorzuverarbeiten.

Ich melde mich mal mit Ergebnissen wieder und bedanke mich für deine sehr aufschlussreichen Stellungnahmen,

Viele Grüße, Franz

Hallo Thomas,

Aber hätte man , wenn es denn nur auf den Platz und Leistung
ankommt , nicht gleich für jede sprache einen VIEW angeboten ?
Dann hat der Server die Aufgabe schon erledigt und in der
benötigten sprache vorliegen.

Ja, das wird auch die Lösung werden:

set @stmt1 = concat(„select „,@languagecode,“_Text1 as Text1“,…
prepare, execute.

Ich melde mich dann mal mit Ergebnissen wieder und bedanke mich herzlichst bei dir für all die super Tipps.

Viele Grüße, Franz