Boolische Einträge in MySQL
Schönen guten Morgen,
ich habe eine Frage,
und zwar gibt es unter Access ja eine Boolische Auswahl (Ja/Nein). Nun möchte ich diesen boolischen Eintrag in MySQL übernehmen. Ist es nun richtig, dass ich da ENUM benutzen muss oder gibt es eine bessere Lösung?
und dann noch der Datentyp Double unter Access kann ich diesen Datentypen auch unter MySQL verwenden oder soll ich da besser Float nehmen?
Und für OLE-Objekt und MEMO Datentypen in Access welcher Datentypen eignen sich da in MySQL?
Für Eure Hilfe wäre ich euch dankbar
Viele Grüße
Pawlos
ich habe eine Frage,
und zwar gibt es unter Access ja eine Boolische Auswahl (Ja/Nein). Nun möchte ich diesen boolischen Eintrag in MySQL übernehmen. Ist es nun richtig, dass ich da ENUM benutzen muss oder gibt es eine bessere Lösung?
und dann noch der Datentyp Double unter Access kann ich diesen Datentypen auch unter MySQL verwenden oder soll ich da besser Float nehmen?
Und für OLE-Objekt und MEMO Datentypen in Access welcher Datentypen eignen sich da in MySQL?
Für Eure Hilfe wäre ich euch dankbar
Viele Grüße
Pawlos
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 69719
Url: https://administrator.de/contentid/69719
Ausgedruckt am: 20.11.2024 um 00:11 Uhr
5 Kommentare
Neuester Kommentar
Moin Pawlos,
bei BOOLEAN ist es (wie bei den meisten Datenbanksystemen) auch bei mySQL eine Näherungslösung bzw. Geschmacksfrage, wie Du so etwas abbildest.
Bei mySQL hast Du die Wahl zwischen ENUM, TINYINT oder auch einem selbstgestrikcten CHAR(1)-Feld.
Näherungslösung bleibt es, weil Du den meisten ODBC-Treibern nicht erklären kannst, was Du mit diesem Datentyp ("J/N-Feld") meinst.
So kommt es mindestens zu Darstellungsproblemen, oft aber auch dazu, dass über ODBC-Zugriffe eben doch andere Werte als ja/nein oder TRUE/FALSE oder 0/1 in die Tabellen gelangen können.
--> mach es willkürlich nach Belieben, aber dann für ALLE Tabellenfelder einheitlich.
Für MEMO-Felder aus M$-Access, meines Wissens nach 32767 Zeichen lang wäre sicherlich vollkommen ausreichend der Typ TEXT ( 2^16 Zeichen = 131072).
Ein MEDIUMTEXT, der von vielen dafür verwendet wird mit 2^^24 Zeichen = 33554432 Byte ist pures Neureichen-Rumgeprotze.
Wenn sogar noch realistische Erkenntnisse über die vorhandene Nutzung der M$-Access-Memofelder vorliegen, wirst Du eventuell feststellen, dass Dir auch VARCHAR(1000) dicke als Ersatz reicht.
Grüße
Biber
bei BOOLEAN ist es (wie bei den meisten Datenbanksystemen) auch bei mySQL eine Näherungslösung bzw. Geschmacksfrage, wie Du so etwas abbildest.
Bei mySQL hast Du die Wahl zwischen ENUM, TINYINT oder auch einem selbstgestrikcten CHAR(1)-Feld.
Näherungslösung bleibt es, weil Du den meisten ODBC-Treibern nicht erklären kannst, was Du mit diesem Datentyp ("J/N-Feld") meinst.
So kommt es mindestens zu Darstellungsproblemen, oft aber auch dazu, dass über ODBC-Zugriffe eben doch andere Werte als ja/nein oder TRUE/FALSE oder 0/1 in die Tabellen gelangen können.
--> mach es willkürlich nach Belieben, aber dann für ALLE Tabellenfelder einheitlich.
Für MEMO-Felder aus M$-Access, meines Wissens nach 32767 Zeichen lang wäre sicherlich vollkommen ausreichend der Typ TEXT ( 2^16 Zeichen = 131072).
Ein MEDIUMTEXT, der von vielen dafür verwendet wird mit 2^^24 Zeichen = 33554432 Byte ist pures Neureichen-Rumgeprotze.
Wenn sogar noch realistische Erkenntnisse über die vorhandene Nutzung der M$-Access-Memofelder vorliegen, wirst Du eventuell feststellen, dass Dir auch VARCHAR(1000) dicke als Ersatz reicht.
Grüße
Biber
Moin Pawlos,
die Max-Größe eines OLE-Objects kann IMHO (theoretisch; ungesicherte Herstellerangaben!) bis 128 MByte sein... dann wären sowohl BLOB wie MEDIUMBLOB zu klein im worst case.
--> also für Ängstliche: LONGBLOB.
--> für Realos: ja, was hast Du denn da drin im Access? Wenn die ganze *.mdb nur 30 MByte groß ist, dann wirst Du beim Migrieren keine LONGBLOBs brauchen...
Aus dem, was Access als DOUBLE bezeichnet würde formal ein mySQL-DOUBLE.
FLOAT würde aber reichen - das wäre zwar nur ein "einfacher Fließkommawert" und kein "~ mit doppelter Genauigkeit...
Aber hey, Du wirst ja in einer bestehenden ACCESS-"Datenbank" keine Satellitenumlaufbahnen berechnet haben...
Grüße
Biber
die Max-Größe eines OLE-Objects kann IMHO (theoretisch; ungesicherte Herstellerangaben!) bis 128 MByte sein... dann wären sowohl BLOB wie MEDIUMBLOB zu klein im worst case.
--> also für Ängstliche: LONGBLOB.
--> für Realos: ja, was hast Du denn da drin im Access? Wenn die ganze *.mdb nur 30 MByte groß ist, dann wirst Du beim Migrieren keine LONGBLOBs brauchen...
Aus dem, was Access als DOUBLE bezeichnet würde formal ein mySQL-DOUBLE.
FLOAT würde aber reichen - das wäre zwar nur ein "einfacher Fließkommawert" und kein "~ mit doppelter Genauigkeit...
Aber hey, Du wirst ja in einer bestehenden ACCESS-"Datenbank" keine Satellitenumlaufbahnen berechnet haben...
Grüße
Biber
Moin Pawlos,
Ach, weißt Du, wenn ich mich belästigt fühlen sollte, dann werde ich schon Mittel und Wege finden, es zu zeigen...
Außerdem bin ich ja einer von vielen, die hier gern und gratis ihr Wissen weitergeben.
Weil hier jeder nur von und mit anderen lernen kann.
Diesen Beitrag hier bitte ich Dich auf gelöst zu setzen, wenn die Frage für Dich beantwortet ist.
[Edit 2.10.2007] THX@pawlos fürs Haken-Setzen. Beitrag geschlossen. [/Edit]
Für die nächste Frage kannst Du gerne einen neuen Beitrag eröffnen.
Grüße
Biber
Darf ich fragen ob ich dich bei eventuell weiteren Fragen zu MySQL belästigen werden darf?
Ach, weißt Du, wenn ich mich belästigt fühlen sollte, dann werde ich schon Mittel und Wege finden, es zu zeigen...
Außerdem bin ich ja einer von vielen, die hier gern und gratis ihr Wissen weitergeben.
Weil hier jeder nur von und mit anderen lernen kann.
Diesen Beitrag hier bitte ich Dich auf gelöst zu setzen, wenn die Frage für Dich beantwortet ist.
[Edit 2.10.2007] THX@pawlos fürs Haken-Setzen. Beitrag geschlossen. [/Edit]
Für die nächste Frage kannst Du gerne einen neuen Beitrag eröffnen.
Grüße
Biber