MySQL 5 macht unter Windows alles klein
Rob Scott
alles richtig mit Groß- und Kleinbuchstaben in der Datenbank erstellt.
Das gleiche Creates.sql auf einer frisch installierten 5.0.37 liefert
grundsätzlich alle Tabellen und Feldnamen nur in Kleinbuchstaben.
Reinstallation mit vorherigem manuellen Aufräumen in der Registry hat
alles nichts gebracht. Weiss jemand von Euch warum das so ist, und wie
sich das ggfs. abstellen lässt?
Danke schon im Voraus
rob*
Björn Steinbrink
Das liegt daran, dass MySQL Datenbank- und Tabellennamen direkt auf
Verzeichnisse und Dateien abbildet. Ob die dann case-sensitive oder case-
insensitive sind hängt vom Dateisystem ab.
Für den case-insensitive Fall (z.B. Windows) lässt sich für MyISAM
Tabellen noch einstellen, ob die Namen generell kleingeschrieben werden
oder Groß-/Kleinschreibung zumindest für die Anzeige beibehalten werden.
Für InnoDB ist das nicht drin, case-insensitive heisst da immer auch
Kleinschreibung.
Mehr Details gibt's hier:
http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html
Björn
Dominik Echterbruch
> War heute etwas am Verzweifeln. Grund: Unter Linux hat mein Creates.sql
> alles richtig mit Groß- und Kleinbuchstaben in der Datenbank erstellt.
> Das gleiche Creates.sql auf einer frisch installierten 5.0.37 liefert
> grundsätzlich alle Tabellen und Feldnamen nur in Kleinbuchstaben.
Es hat sich also immer noch nicht herumgesprochen, daß es M$ völlig egal
ist, daß man das eine Wort groß und das andere klein geschrieben hat und
daß das einen Grund haben könnte. Wundert mich nur, daß die
Rechtschreibkorrektur in Word das unterscheiden kann...
> Reinstallation mit vorherigem manuellen Aufräumen in der Registry hat
> alles nichts gebracht. Weiss jemand von Euch warum das so ist, und wie
> sich das ggfs. abstellen lässt?
Abstellen läßt sich das nur durch Reinstallation des Betriebssystems
nach manuellem Austausch der Installations-CD gegen irgendwas gescheites.
Man hat auch in der Doku ein paar Worte über das Thema verloren:
http://dev.mysql.com/doc/refman/5.0/en/windows-vs-unix.html
Interessant ist dann auch der weiterführende Link am Ende des
betreffenden Absatzes.
Grüße,
Dominik
Rob Scott
>> Unter Linux hat mein Creates.sql
>> alles richtig mit Groß- und Kleinbuchstaben in der Datenbank erstellt.
>> grundsätzlich alle Tabellen und Feldnamen nur in Kleinbuchstaben.
>
> Verzeichnisse und Dateien abbildet. Ob die dann case-sensitive oder case-
> insensitive sind hängt vom Dateisystem ab.
> Für den case-insensitive Fall (z.B. Windows) lässt sich für MyISAM
> Tabellen noch einstellen, ob die Namen generell kleingeschrieben werden
> oder Groß-/Kleinschreibung zumindest für die Anzeige beibehalten werden.
> Für InnoDB ist das nicht drin, case-insensitive heisst da immer auch
> Kleinschreibung.
>
> Mehr Details gibt's hier:
> http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html
Danke erst mal für die rasche Antwort.
Ok. Ich vergaß vorhin im Text zu erwähnen, dass unter Windows und mit
NTFS als Filesystem gearbeitet wird. Sowohl unter Linux als auch unter
Windows ist InnoDB im Einsatz.
Der oben erwähnte Inhalt besagt nichts darüber aus, wie sich die reine
Kleinschreibung unter Windows/NTFS abstellen lässt (vielleicht bin ich
inzwischen zu müde um es zu sehen :) ).
GRuKltabellenUndFeldNamen das ließt sich irgendwie besser als nur klein
und es soll sowohl unter Linux als auch Windows GuKl sein.
rob*
Rob Scott
Hallo Dominik,
das ist der entscheidende Hinweis. Danke dafür erst mal.
Wie bekommt das MS dann hin, dass man im FS ein Verzeichnis oder eine
Datei TeST anlegen kann und die weiterhin so angezeigt wird?
programmierungsmäßig gibt es unter NTFS wohl eigentlich keinen Grund,
dass man das nicht auseinander bekommt.
Dass MS sich auf Filesystemebene selbst nicht darum kümmert ob Groß oder
Klein ist eigentlich sekundär, solange nicht ein zweites Mal eine
Tabelle/Datei namens 'test' oder 'teSt' usw. gibt. Oder sehe ich das falsch?
Mit gescheitem OS gebe ich Dir recht :) es ist nur so, dass die DB
sowohl unter Linux als auch ein Abzug davon auf einem lokalen
Windows-Server (unterwegs auf dem Notebook) laufen lassen möchte. Damit
ist das so gut wie geknickt (es sei denn ich stelle alles um). Gefällt
mir nicht, eigentlich...
Also ist MySQL dann MS-Seitig doch nicht soweit wie ich dachte. :( blöd.
rob*
Rob Scott
> Dominik Echterbruch schrieb:
> Dass MS sich auf Filesystemebene selbst nicht darum kümmert ob Groß oder
> Klein ist eigentlich sekundär, solange nicht ein zweites Mal eine
> Tabelle/Datei namens 'test' oder 'teSt' usw. gibt. Oder sehe ich das
> falsch?
Ergänzungsfrage:
Was geschieht, wenn ich auf FSys Ebene zu Fuß umbenenne - was muss ich
intern machen (geht das überhaupt?) - damit die Tabellen im System
wieder konsistent mitgezogen werden.
@mysql (sollte jemand mitlesen): Leute das ist armseelig was Ihr da
macht. Wie schon vorhin erwähnt: Klar kann es nicht zwei geben ... aber
das sollte nicht Eure Sorge sein.
rob*
Andreas Kretschmer
> @mysql (sollte jemand mitlesen): Leute das ist armseelig was Ihr da
> macht. Wie schon vorhin erwähnt: Klar kann es nicht zwei geben ... aber
> das sollte nicht Eure Sorge sein.
Du verbuchselst da einige Dinge:
- das ist eine NG zum Thema, nicht die Supportmannschaft des Herstellers
- wieviel genau hast Du bezahlt, daß Du das Recht Dir rausnimmst, so
rumzutönen?
- niemand zwingt Dich, das 'armseelig' gemachte zu nutzen
- in der SQL-Spec steht IMHO nix davon, daß Bezeichner case-sensitiv
sein müssen
- es gibt weniger 'armseelige' Systeme, die auf Wunsch und
filesystemunabhängig case-sensitiv arbeiten können
end
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
Rob Scott
> begin Rob Scott schrieb:
>> @mysql (sollte jemand mitlesen): Leute das ist armseelig was Ihr da
>> macht.
> - das ist eine NG zum Thema, nicht die Supportmannschaft des Herstellers
ist klar. Nur lesen auch bisweilen Leute mit die vom Hersteller sind.
Wie Du reagiert hast, könntest Du dazu zählen ;-) . Vielleicht war das
ein wenig zu direkt. Hiermit zurückgerudert - ok?
Jedoch und das sage ich aus innerster Überzeugung: Wenn man Geld für was
verlangt, dann sollte man's möglichst gut machen. Und optimal kann man
das nun wirklich nicht gerade nennen.
Zum Bezahlmodus: Es gibt Leute die evaluieren und müssen entscheiden.
Wenn es nach uns hier ginge, dann würde bestimmt kein Windows drunter
gesteckt.
Alles klar?
rob*
Andreas Kretschmer
> Andreas Kretschmer schrieb:
>> begin Rob Scott schrieb:
>>> @mysql (sollte jemand mitlesen): Leute das ist armseelig was Ihr da
>>> macht.
>
>> - das ist eine NG zum Thema, nicht die Supportmannschaft des Herstellers
>
> ist klar. Nur lesen auch bisweilen Leute mit die vom Hersteller sind.
> Wie Du reagiert hast, könntest Du dazu zählen ;-) . Vielleicht war das
Nein. Ich nutze es nicht einmal. Weil - es gibt besseres.
> Jedoch und das sage ich aus innerster Überzeugung: Wenn man Geld für was
> verlangt, dann sollte man's möglichst gut machen. Und optimal kann man
> das nun wirklich nicht gerade nennen.
Nicht immer korreliert der Preis mit der Qualität.
Klaus Ketelaer
> begin_ Rob Scott schrieb:
>> Andreas Kretschmer schrieb:
>>> begin Rob Scott schrieb:
>>>> @mysql (sollte jemand mitlesen): Leute das ist armseelig was Ihr da
>>>> macht.
>>
>>> - das ist eine NG zum Thema, nicht die Supportmannschaft des Herstellers
>>
>> ist klar. Nur lesen auch bisweilen Leute mit die vom Hersteller sind.
>> Wie Du reagiert hast, könntest Du dazu zählen ;-) . Vielleicht war das
>
> Nein. Ich nutze es nicht einmal. Weil - es gibt besseres.
M$ SQL-Server?
SCNR
Gruß
Klaus
joachi...@outcome-ub.de
Warum ist das schlimm?
Du kannst unter Linux lower_case_table_names=1 setzen und hast dann
auf beiden Systemen identisches Verhalten.
Gruß,
Joachim
Claus Reibenstein
> Andreas Kretschmer schrieb:
>
>> [nichts Wichtiges]
>
> ist klar. Nur lesen auch bisweilen Leute mit die vom Hersteller sind.
> Wie Du reagiert hast, könntest Du dazu zählen ;-)
*Prust* Der war gut :-)
> Jedoch und das sage ich aus innerster Überzeugung: Wenn man Geld für was
> verlangt, dann sollte man's möglichst gut machen.
Wieso "Geld verlangt"? Habt Ihr für MySQL etwa was bezahlt?
Gruß. Claus
Rob Scott
Claus Reibenstein schrieb:
>> Jedoch und das sage ich aus innerster Überzeugung: Wenn man Geld für was
>> verlangt, dann sollte man's möglichst gut machen.
>
> Wieso "Geld verlangt"? Habt Ihr für MySQL etwa was bezahlt?
Nun, bis jetzt noch nicht, wenn das Projekt aber richtig losgeht und
MySQL sich tatsächlich als plattformübergreifen dafür erweisen sollte
(wir haben es noch nicht ganz aufgegeben), dann wird sicher auch was für
die Leute bei MySQL AB abfallen.
Wir haben erst mal das Community-Projekt angesehen - vermutlich
unterscheidet es sich in solch prinzipiellen Dingen nicht von der
Enterprise Version.
MySQL AB wird kaum zwei Branches pflegen und zwei Dokus mitziehen. Das
gehört in die Kommerzwelt und kommt in OSS so gut wie nicht vor. Ich
denke aber das ist jetzt schon verdammt OT und gehört nicht (mehr) hierhin.
rob*
Rob Scott
Danke für den Tipp. Die Idee hatten wir auch schon.
Es gibt bereits lauffähige Prototypen. Die wurden unter VB und Jet
entwickelt. Sollen parallel auch weiterhin benutzt werden. In der
bisherigen Lösung gibt es massenweise so richtig komplexe SQL-Statements
und -Ausdrücke die es dann alle umzuwandeln gilt. Das wird nicht
praktikabel sein, und der Kunde auch sicher nicht zahlen (wollen).
Gibt es eine Möglichkeit dem ODBC-Treiber das irgendwie bei zu bringen,
die GuKl-Tabellennamen zu ignorieren. Wenn ja, dann wäre das
möglicherweise eine Lösung.
Sonst: Blöd gelaufen. :-( noch dazu wo wir eigentlich von MS weg wollen.
rob*
Dominik Echterbruch
>
> Gibt es eine Möglichkeit dem ODBC-Treiber das irgendwie bei zu bringen,
> die GuKl-Tabellennamen zu ignorieren. Wenn ja, dann wäre das
> möglicherweise eine Lösung.
>
> Sonst: Blöd gelaufen. :-( noch dazu wo wir eigentlich von MS weg wollen.
OK, das hier wird mich vermutlich den Rest meines Lebens verfolgen, aber:
Es gibt ja auch noch was anderes, als MySQL und MS-SQL. Andreas
Kretschmer hatte das ja schon angesprochen und wird sich jetzt richtig
freuen: PostgreSQL ist eine echte Alternative zu den schwergewichtigen
kommerziellen Datenbanken.
Und in Sachen Geschwindigkeit steht die auch nicht schlecht da. Kommt
zwar auf den Anwendungsfall an, aber ich habe gerade unsere
Datensicherung (bacula, falls es jemanden interessiert) von MySQL auf
PostgreSQL migriert, weil (man höre und staune) ersteres zu langsam ist.
Hoffe, das hilft ein wenig. Sonst habe ich mich jetzt hier völlig
umsonst geoutet ;)
Grüße,
Dominik
Andreas Scherbaum
>
> Sonst: Blöd gelaufen. :-( noch dazu wo wir eigentlich von MS weg wollen.
Was hat euch dann bewegt, Mysql zu nehmen?
Und warum evaluiert man so etwas nicht vorher, bevor man
eine Menge Code schreibt?
Bye
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
Axel Schwenke
> joachi...@outcome-ub.de schrieb:
>>
>> Du kannst unter Linux lower_case_table_names=1 setzen und hast dann
>> auf beiden Systemen identisches Verhalten.
>
> Danke für den Tipp. Die Idee hatten wir auch schon.
Hast du auch mal weiter gelesen? Für diese Option gibt es 3 Werte.
Wenn ihr wirklich ausschließlich InnoDB verwendet, dann paßt
lower_case_table_names=0.
Das Problem mit lower_case_table_names=0 und Windows ist folgendes:
Wenn zwei Clients unabhängig auf die Tabellen FooBar und fOObAR
zugreifen, dann behandelt MySQL beide Tabellen als unabhängige
Objekte. Dummerweise sieht das Windows-Filesystem das anders und
liefert jeweils die gleiche Tabelle (meinetwegen fOobAr). Weil
MySQL die beiden Tabellen für unabhängig hält, schreibt es bpsw.
unbekümmert parallel in die selben Files, was dann erwartungsgemäß
zum Daten-GAU führt.
Da allerdings InnoDB Tabellen über das interne (case-sensitive)
Data-Dictionary verwaltet, hat es dieses Problem nicht.
> Es gibt bereits lauffähige Prototypen. Die wurden unter VB und Jet
> entwickelt. Sollen parallel auch weiterhin benutzt werden. In der
> bisherigen Lösung gibt es massenweise so richtig komplexe SQL-Statements
> und -Ausdrücke die es dann alle umzuwandeln gilt. Das wird nicht
> praktikabel sein, und der Kunde auch sicher nicht zahlen (wollen).
Irgendwie hast du etwas nicht verstanden. Du mußt genau gar kein
Statement umschreiben. Schreib deine Statements so, daß sie den
richtigen case [1] verwenden (d.h. unter Linux funktionieren).
Dann werden sie auch unter Windows funktionieren. Nur anders
herum muß das nicht funktionieren.
[1] im MySQL-Kontext heißt "richtig" = konsistente Groß-/Klein-
Schreibung. Falls ihr euch ursprünglich auf den SQL-Standard
gestützt habt, ist wahrscheinlich alles schon F.U.B.A.R.
> Gibt es eine Möglichkeit dem ODBC-Treiber das irgendwie bei zu bringen,
> die GuKl-Tabellennamen zu ignorieren. Wenn ja, dann wäre das
> möglicherweise eine Lösung.
Auch noch ODBC. Performance wollt ihr dann wohl nicht. Oder?
> Sonst: Blöd gelaufen. :-( noch dazu wo wir eigentlich von MS weg wollen.
Dann solltet ihr das *konsequent* durchziehen. Windows ist
definitiv nicht die Plattform der Wahl für MySQL. Zumindest
nicht für den produktiven Betrieb. Für die Entwicklung dann
allerdings auch nicht - immerhin könnte man ja kaputte SQL-
Statements schreiben, die unter Windows funktionieren, aber
nicht unter Linux.
Falls eure Entwickler unbedingt Windows haben müssen, dann
packt denen halt das MySQL in eine Linux-VM.
XL
Rob Scott
> lower_case_table_names=0.
ich werde mich morgen selber nochmal hinsetzen und alle Möglichkeiten
durchspielen.
> Wenn zwei Clients unabhängig auf die Tabellen FooBar und fOObAR
> zugreifen, dann behandelt MySQL beide Tabellen als unabhängige
> Objekte.
Das war schon klar. Auch die sich daraus ergebenden Implikationen. Wenn
es aber nur eine Tabellen Variante hat? Eine Option
ignore_case_of_tablenames=1 wäre da halt hilfreich. Es ging nämlich
schon damit los, dass unter Windows views anders angelegt wurden als
unter Linux. Ich probiere das morgen nochmal selbst.
> Auch noch ODBC. Performance wollt ihr dann wohl nicht. Oder?
Die Prototypen werden bereits seit geraumer Zeit genutzt. Hochperformant
muss das nicht sein, nein. Stabil ja. Läuft nur in LAN-Umgebung. Nix
Webserver usw.
> Dann solltet ihr das *konsequent* durchziehen. Windows ist
> definitiv nicht die Plattform der Wahl für MySQL. Zumindest
> nicht für den produktiven Betrieb. Für die Entwicklung dann
> allerdings auch nicht - immerhin könnte man ja kaputte SQL-
> Statements schreiben, die unter Windows funktionieren, aber
> nicht unter Linux.
>
> Falls eure Entwickler ...
Es geht nicht um die Entwickler. Wir arbeiten unter Linux und Windows.
Letzteres gezwungener Maßen, da die Clients beim Kunden unter Windows
und nicht unter Linux laufen. Eine echte Web-centric Lösung geht leider
auch nicht (spezielle Hardware die nur unter Windows an den Clients
läuft). Es ist Kundenwunsch, dass sich Auswertungen offline etwa auf
Notebooks von Snapshots fahren lassen. Dazu muss ein lokaler SQL-Server
installiert sein (nein MS nicht mehr :-) ).
Andreas schrieb von Postgress. Ja da ist auch schon daran gedacht
worden. Das Handling der Datenbanken war in der Vergangenheit bei MySQL
deutlich einfacher. Kann persönlich allerdings nicht viel dazu sagen.
Hab ich keine Ahnung (noch nicht). Es gibt sicherlich nichts, was
Postgress nicht auch könnte. Ich will hier auch nicht einen riesen
Thread pro/contra Pstgrs/mysql lostreten.
Andere Möglichkeit wäre natürlich für die Auswerterei die Daten nicht
1:1 zu ziehen, sondern mit einem kleinen lokalen SQL-Server abzuhandeln.
ApacheDB / SQLite whatever. Grübel.. ich denke da ist das letzte Wort
noch nicht gesprochen.
Danke in jedem Fall für Eure Anregungen.
rob*
Dieter Noeth
> Das Problem mit lower_case_table_names=0 und Windows ist folgendes:
> Wenn zwei Clients unabhängig auf die Tabellen FooBar und fOObAR
> zugreifen, dann behandelt MySQL beide Tabellen als unabhängige
> Objekte. Dummerweise sieht das Windows-Filesystem das anders und
> liefert jeweils die gleiche Tabelle (meinetwegen fOobAr). Weil
> MySQL die beiden Tabellen für unabhängig hält, schreibt es bpsw.
> unbekümmert parallel in die selben Files, was dann erwartungsgemäß
> zum Daten-GAU führt.
>
> Da allerdings InnoDB Tabellen über das interne (case-sensitive)
> Data-Dictionary verwaltet, hat es dieses Problem nicht.
>
>> Es gibt bereits lauffähige Prototypen. Die wurden unter VB und Jet
>> entwickelt. Sollen parallel auch weiterhin benutzt werden. In der
>> bisherigen Lösung gibt es massenweise so richtig komplexe SQL-Statements
>> und -Ausdrücke die es dann alle umzuwandeln gilt. Das wird nicht
>> praktikabel sein, und der Kunde auch sicher nicht zahlen (wollen).
>
> Irgendwie hast du etwas nicht verstanden. Du mußt genau gar kein
> Statement umschreiben. Schreib deine Statements so, daß sie den
> richtigen case [1] verwenden (d.h. unter Linux funktionieren).
> Dann werden sie auch unter Windows funktionieren. Nur anders
> herum muß das nicht funktionieren.
Oder nimm einfach ein DBMS, dass sich an Standard SQL hält.
Neben den anderen schon genannten wäre v.a. Firebird eine gute Wahl...
> [1] im MySQL-Kontext heißt "richtig" = konsistente Groß-/Klein-
> Schreibung. Falls ihr euch ursprünglich auf den SQL-Standard
> gestützt habt, ist wahrscheinlich alles schon F.U.B.A.R.
Was hat Großschreibung mit Standard SQL zu tun?
Nur im alten SQL92 Entry Level durften Bezeichner nur in Grossbuchstaben
geschrieben werden, ansonsten ist gemischte Schreibweise schon immer
erlaubt gewesen.
Gemischte Bezeichner sind aber nicht case-sensitive.
Nur ein Bezeichner in doppelten Anführungszeichen ist case-sensitive
(was ich persönlich für ziemlich dämlich halte, ja, auch in C/Unix).
>> Gibt es eine Möglichkeit dem ODBC-Treiber das irgendwie bei zu bringen,
>> die GuKl-Tabellennamen zu ignorieren. Wenn ja, dann wäre das
>> möglicherweise eine Lösung.
>
> Auch noch ODBC. Performance wollt ihr dann wohl nicht. Oder?
Was hast du gegen ODBC? Nur weil MS das Trademark drauf hat(te)?
ODBC 3.0 ist ziemlich kompatibel zu Standard SQL/CLI und Treiber gibt's
auch unter Unix.
Dieter
Andreas Kretschmer
> Andreas schrieb von Postgress. Ja da ist auch schon daran gedacht
Nur in der Signatur, glaub ich ;-)
> worden. Das Handling der Datenbanken war in der Vergangenheit bei MySQL
> deutlich einfacher. Kann persönlich allerdings nicht viel dazu sagen.
> Hab ich keine Ahnung (noch nicht). Es gibt sicherlich nichts, was
> Postgress nicht auch könnte. Ich will hier auch nicht einen riesen
> Thread pro/contra Pstgrs/mysql lostreten.
PG läßt sich mittlerweile deutlich einfacher unter Win installieren.
Ohne jetzt pro/contra machen zu wollen: ob PG oder MySQL für Deinen
Zweck sinnvoller ist, hängt von Rahmenbedingungen ab, z.B. ob Du Wert
auf RI legst und wie komplex die Anfragen sind. Es gibt ganz sicher
Anwendungen, wo MySQL Vorteile hat, wenn Du z.B. auf Features wie RI und
Transaktionen verzichten und mit MyISAM arbeiten kannst - dann ist MySQL
schneller.
end
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
Joachim Zobel
> joachi...@outcome-ub.de schrieb:
>> Du kannst unter Linux lower_case_table_names=1 setzen und hast dann
>> auf beiden Systemen identisches Verhalten.
>
> Danke für den Tipp. Die Idee hatten wir auch schon.
>
> Es gibt bereits lauffähige Prototypen. Die wurden unter VB und Jet
> entwickelt. Sollen parallel auch weiterhin benutzt werden. In der
> bisherigen Lösung gibt es massenweise so richtig komplexe SQL-Statements
> und -Ausdrücke die es dann alle umzuwandeln gilt. Das wird nicht
> praktikabel sein, und der Kunde auch sicher nicht zahlen (wollen).
Solange Ihr die Datenbank mit obiger Option neu anlegt, ist das
kein Problem. Ein Problem könnte sein, das Ihr nicht zurück könnt, sowie
Quellcode existiert, der sich nicht mehr um den Case der Tabellennamen
kümmert.
Gruß,
Joachim
Daniel Fischer
> MySQL AB wird kaum zwei Branches pflegen und zwei Dokus mitziehen.
Es gibt zwei Branches von MySQL 5.0, allerdings ist der für zahlende
Kunden auch öffentlich und Änderungen gelangen auch in den Community-
Branch. Nur nicht umgekehrt, d.h. Patches aus der Community bleiben im
Community-Branch.
Im Moment ist der nennenswerte Unterschied zwischen 5.0.37
(dem letzten Community-Release) und 5.0.36 (dem letzten Bezahl-Release)
daher, dass die Community-Variante Profiling kann und die andere nicht.
Gruß
Daniel
Axel Schwenke
> Axel Schwenke schrieb:
>> lower_case_table_names=0.
>
> ich werde mich morgen selber nochmal hinsetzen und alle Möglichkeiten
> durchspielen.
>
>> Wenn zwei Clients unabhängig auf die Tabellen FooBar und fOObAR
>> zugreifen, dann behandelt MySQL beide Tabellen als unabhängige
>> Objekte.
>
> Das war schon klar. Auch die sich daraus ergebenden Implikationen. Wenn
> es aber nur eine Tabellen Variante hat? Eine Option
> ignore_case_of_tablenames=1 wäre da halt hilfreich.
Im Endeffekt ist das eine der Bedeutungen von lower_case_table_names.
>> Dann solltet ihr das *konsequent* durchziehen. Windows ist
>> definitiv nicht die Plattform der Wahl für MySQL. Zumindest
>> nicht für den produktiven Betrieb. Für die Entwicklung dann
>> allerdings auch nicht - immerhin könnte man ja kaputte SQL-
>> Statements schreiben, die unter Windows funktionieren, aber
>> nicht unter Linux.
>>
>> Falls eure Entwickler ...
>
> Es geht nicht um die Entwickler. Wir arbeiten unter Linux und Windows.
> Letzteres gezwungener Maßen, da die Clients beim Kunden unter Windows
> und nicht unter Linux laufen. Eine echte Web-centric Lösung geht leider
> auch nicht (spezielle Hardware die nur unter Windows an den Clients
> läuft). Es ist Kundenwunsch, dass sich Auswertungen offline etwa auf
> Notebooks von Snapshots fahren lassen. Dazu muss ein lokaler SQL-Server
> installiert sein.
Also wirklich Deployment auf Windows. Dann müßt ihr auf jeden Fall
InnoDB nehmen. Sonst habt ihr nach jedem unsauberen Shutdown (sprich:
hartem Ausschalten des Rechners) eine kaputte Datenbank. Nach meiner
Erfahrung schalten 95% der Windows-User ihren Rechner so aus.
XL
Axel Schwenke
> Axel Schwenke wrote:
>
>> Du mußt genau gar kein
>> Statement umschreiben. Schreib deine Statements so, daß sie den
>> richtigen case [1] verwenden (d.h. unter Linux funktionieren).
>> Dann werden sie auch unter Windows funktionieren. Nur anders
>> herum muß das nicht funktionieren.
>
> Oder nimm einfach ein DBMS, dass sich an Standard SQL hält.
> Neben den anderen schon genannten wäre v.a. Firebird eine gute Wahl...
>
>> [1] im MySQL-Kontext heißt "richtig" = konsistente Groß-/Klein-
>> Schreibung. Falls ihr euch ursprünglich auf den SQL-Standard
>> gestützt habt, ist wahrscheinlich alles schon F.U.B.A.R.
>
> Was hat Großschreibung mit Standard SQL zu tun?
Schrieb ich das? Ich wollte nur darauf hinweisen, daß MySQL sich bei
der Case-Sensitivität von Bezeichnern *nicht* an den SQL-Standard hält.
Wenn man also fleißig Groß-/Kleinschreibung gemsicht hat (weil man das
laut Standard ja darf) - dann wird MySQL/Windows das vielleicht noch
schlucken, MySQL/UNIX allerdings nicht.
> Nur im alten SQL92 Entry Level durften Bezeichner nur in Grossbuchstaben
> geschrieben werden, ansonsten ist gemischte Schreibweise schon immer
> erlaubt gewesen.
> Gemischte Bezeichner sind aber nicht case-sensitive.
> Nur ein Bezeichner in doppelten Anführungszeichen ist case-sensitive
> (was ich persönlich für ziemlich dämlich halte, ja, auch in C/Unix).
Das ist mir bekannt. Und ich teile deine Ansicht über Dämlichkeit.
>> Auch noch ODBC. Performance wollt ihr dann wohl nicht. Oder?
>
> Was hast du gegen ODBC?
Es ist ein weiterer Layer zwischen der nativen API und der Applikation.
Dieses Layer-Stapeln ist eine scheußliche Unsitte und ich sehe es heute
an viel zu vielen Stellen (das kam IMHO massiv mit Java auf, als alle
auf der "Rechenleistung kostet doch nix" Welle schwammen).
Und wenn ich mir die ca. 1000 Konfigurations-Optionen für myODBC
ansehe, dann möchte ich *gar* *nicht* wissen, was da unter der Haube
alles passiert. Dann die Workarounds, um die fehlenden API-Teile nach-
zubauen (z.B. ist INSERT <auto-increment> ... gefolgt von SELECT auto
WHERE auto IS NULL eine Spezialmethode zur Abfrage der generierten id,
die extra für (kaputte?) ODBC-Anwendungen existiert).
Nicht zu vergessen die diversen Bugs, die man nur hat, wenn man ODBC
verwendet.
Nee, nee. Bleib mir damit 3 Schritt vom Leibe!
XL
Rob Scott
> Also wirklich Deployment auf Windows. Dann müßt ihr auf jeden Fall
> InnoDB nehmen. Sonst habt ihr nach jedem unsauberen Shutdown (sprich:
> hartem Ausschalten des Rechners) eine kaputte Datenbank. Nach meiner
> Erfahrung schalten 95% der Windows-User ihren Rechner so aus.
Autsch!
Gut zu wissen.
rob*