SQL Schlauer Datenbank aufbau

[som3]

Hallo CB´ler,

Ich bräuchte mal ein paar ratschläge und ideen zum aufbau einer Datenbank von mir.
Datensätze bleiben meist nur Temporär für 2-4 Wochen gespeichert.
Für mich ist wichtig das die Datenbank schnell ist und Insert queries schnell gehen.

In der Datenbank werden Informationen zu einem User gespeichert.
Unter anderem den Namen, E-mail, Geburtsdatum und anderer Standard kram.

Das problem stelle ein großes JSON objekt da welches an sich schon eine eigene Tabelle darstellen könnte.

Hier mal ein beispiel JSON Object (Nein im Normalfall stehen da nicht so viele Nullen)

Spoiler

{
 "kind": "youtubeAnalytics#resultTable",
 "columnHeaders": [
  {
   "name": "7DayTotals",
   "columnType": "DIMENSION",
   "dataType": "STRING"

  },

  {
   "name": "views",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "estimatedMinutesWatched",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "averageViewDuration",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "comments",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "favoritesAdded",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "favoritesRemoved",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "likes",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "dislikes",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "shares",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "subscribersGained",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  },

  {
   "name": "subscribersLost",
   "columnType": "METRIC",
   "dataType": "INTEGER"

  }


 ],

 "rows": [
  [
   "2013-10-10",
   2,
   0,
   3,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-01",
   4,
   0,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-28",
   11,
   1,
   8,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-05",
   1,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-07",
   5,
   0,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-27",
   1,
   0,
   21,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-20",
   15,
   1,
   7,
   0,
   0,
   0,
   0,
   0,
   0,
   4,
   0

  ],

  [
   "2013-10-04",
   1,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-17",
   5,
   0,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-19",
   1,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-09",
   3,
   0,
   2,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-16",
   4,
   0,
   12,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-28",
   1,
   0,
   21,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-15",
   20,
   3,
   10,
   0,
   0,
   0,
   0,
   0,
   0,
   5,
   0

  ],

  [
   "2013-10-31",
   4,
   0,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-24",
   1,
   0,
   21,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-17",
   16,
   2,
   10,
   0,
   0,
   0,
   0,
   0,
   0,
   5,
   0

  ],

  [
   "2013-11-03",
   9,
   1,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-25",
   1,
   0,
   21,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-16",
   18,
   3,
   10,
   0,
   0,
   0,
   0,
   0,
   0,
   5,
   0

  ],

  [
   "2013-10-12",
   6,
   0,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-27",
   12,
   1,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-11-12",
   4,
   0,
   11,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-10-15",
   4,
   0,
   12,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-26",
   1,
   0,
   21,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-13",
   6,
   0,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-10",
   4,
   0,
   11,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-02",
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-23",
   10,
   1,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-11-09",
   2,
   0,
   12,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-26",
   13,
   2,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-10-14",
   6,
   0,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-23",
   2,
   0,
   10,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-06",
   9,
   1,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-14",
   15,
   2,
   11,
   0,
   0,
   0,
   0,
   0,
   0,
   5,
   0

  ],

  [
   "2013-10-30",
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-25",
   15,
   2,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-11-30",
   10,
   1,
   8,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-22",
   2,
   0,
   10,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-24",
   15,
   2,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-11-18",
   17,
   2,
   10,
   0,
   0,
   0,
   0,
   0,
   0,
   5,
   0

  ],

  [
   "2013-11-21",
   12,
   2,
   10,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-11-05",
   9,
   1,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-18",
   2,
   0,
   10,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-13",
   10,
   2,
   14,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-10-21",
   1,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-03",
   1,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-11",
   4,
   0,
   11,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-22",
   9,
   1,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   1,
   0

  ],

  [
   "2013-10-07",
   1,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-29",
   10,
   1,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-02",
   9,
   1,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-19",
   20,
   3,
   9,
   0,
   0,
   0,
   0,
   0,
   0,
   4,
   0

  ],

  [
   "2013-10-06",
   1,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-20",
   1,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-08",
   3,
   0,
   2,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-04",
   9,
   1,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-29",
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-01",
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-11-08",
   5,
   0,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ],

  [
   "2013-10-11",
   5,
   0,
   6,
   0,
   0,
   0,
   0,
   0,
   0,
   0,
   0

  ]


 ]


}

Jetzt ist die frage ob man die Daten alle in eine seperate zelle speichert (anzahl der Tage ist immer gleich, sind aber immer andere Tage)
Oder einfach das Json Object als solches speichern und dann immer anzeigen oder eine extra Tabelle nur für das Json objekt mit einer extra spatel mit einer ID zu welchem user die Datensäte gehören.
Es werden immer alle Daten im Json object aufgerufen und angezeigt.

Jemand eine Idee wie ich es am besten speichern kann so das es am effizentesten ist?

Gruß
​Som3

 

[mercsen]

Das JSOn direkt zu speichern macht schon Sinn, wenn du nicht seperat über SQL an die bestandteile musst und die daten hinterher sowieso als JSON ausgegeben werden ist sogar ziemlich sinnvoll nur die informationen die zur idenfikation des JSON objekts dienen als extra spalte zu speichern.

Allerdings könnte man sich ein paar bytes sparen indem man das JSON ändert. Z.B. ist der aufbau von columHeaders immer gleich. Statt immer den Attribut namen anzugeben (name, columnType...) könnte man auch mit numerischen indizes arbeiten und im JS / PHP teil legst dir dann ne Konstante an die auf diesen Index verweist.

Außerdem alle whitspaces entfernen lassen.

Noch einen guten Index wählen und an der performance dürfte es nicht scheitern

 

[Daaron]

Schau doch mal MariaDB 10 (Beta) an, das Ding hat auch NoSQL-Ansätze und, wenn ich mich recht erinner, einen JSON-Import. Evtl. kannst dir damit viel Arbeit ersparen... und schnell ist MariaDB eh.

 

[Fonce]

Die Frage ist aber auch wie der was noch gespeichert wrden muss in welcher Beziehung es zu anderen Daten steht und was mit den Daten gemacht werden soll. Mit wievielen insert/update/find ist zu rechnen? Wie sieht das Verhältnis dieser aus?
Das sind alles Fragen die alleine für die auswahl der DB entscheident sind.
Von MongoDB(arbeite jetzt seit fast einem Jahr damit als DMS Backend) her kann ich nur sagen das hier einer der wichtigsten Punkte ist. "Verwendete große Documente"
Wenn möglich also möglichst mit EmbeddedDocuments arbeiten, da ein großes Dokument schneller gelesen werden kann als viele kleine.
Außerdem hält es den Index klein.

 

[som3]

Es wird immer ein Datensatz, also einmal der name etc und ein solches Json Object in der Datenbank gespeichert.
Und nach einigen Tagen wieder gelöscht.
Also generell keine update oder find queries

Der Insert Prozess muss sehr sehr schnell gehen so das die User Experience am besten ist.
Der User darf keine 5 sekunden warten bis alle daten in der Tabelle gespeichert werden.

Aber gleich das gesamte DB System wechseln? Da bleibe ich lieber bei MySQL

Eine Frage hätte ich aber noch.
Wie kann ich das JSON object in PHP als Tabelle echo´n?
Wenn ich das JSON object so als solches abspeichern muss ich es ja min. 1 Mal als gesamtes wieder aus der DB holen und als Tabelle anzeigen.

 

[mercsen]

json_enocde und json_decode sollten dir dort helfen. damit kannst einen JSOn string in einen assoziativen array umwandeln was den zugriff auf die einzelnen elemente recht simple macht
oder direkt als ein nicht näher definiertes Object

was die geschwindigkeit natürlich erhöhren würde wenn man sich einen eigenen parser schreibt. die daten scheinen ja immer gleich zu bleiben, wie bereits oben erwähnt kann man dann auch auf die attributnamen verzichten und einfach die werte auflisten, per spezifikation weiß man ja was wann kommt (stichwort CSV).

dazu dann eh die frage wieso es ein JSON und nicht einfach ein serialisierter Array / Object genutzt wird. Die daten könnte man dann auch JS geben und das bastelt sich selber nen Object / JSON drauf, so verlagerst du rechenzeit vom server zum clienten.

Wenn man Techniken wie Mysqli::multi_query nutzt dürfte die perfromance auch nicht arg leiden wenn man tatsächlich das ganze ding in eine normalisierte DB kloppt.

je nach server kann es auch vorteile bringen den datensatz einfach in eine datei zu schreiben, hab schon szenarien gehabt da ging das öffnen, auslesen und schließen der datei schneller als erst in einer datenbank zu suchen.

P.S.
wenn es richtig schnell sein muss gibt es auch extremst performante server welche die DB direkt auf einer SSD bereit stellen und eine angepasste SSD version von MySQL anbieten

 

[Daaron]

Aber gleich das gesamte DB System wechseln? Da bleibe ich lieber bei MySQL

MariaDB ist ein Drop-In - Replacement zu MySQL.... also könntest du dessen NoSQL-Aspekte einfach mal blind testen. Wenns nicht gefällt, weglassen... und drüber freuen, dass MariaDB schneller ist als MySQL

 

[AlbertLast]

Wie viele hier,
würde ich auch ein DB Wechsel anregen.

Wobei ich abweichend zu der hier bis jetzt vorherrschenden Meinung
ehr zu PostgreSQL empfehlen würde, weil json indexierbar dort sind.

Der Grund für db Wechsel (egal wohin):
Das du sonst den Vorteil von Json verlierst und der ist
ein Objekt der Freidefinierbar ist, so dass dieser gewechselt werden kann ohne das die DB neu angepasst werden muss.

 

[mambokurt]

Ich finde die Ansätze hier teils etwas Overkill. Wenn ich dein JSON bei uns nach MySQL in ein Textfeld schiebe passiert folgendes:

Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

Wenn ich du wäre, würde ich das als JSON in ein Textfeld packen (vielleicht vorher noch die Leerzeichen raus) und das Ding erst wieder angucken, wenn es wirklich mal perfomanceseitig klemmt (was wohl nicht passieren wird).

Klar kannst du das auch getrennt in Tabellen packen, aber wenn du die Daten eh immer als ganzes brauchst hast du keinerlei Nutzen davon, die Fehleranfälligkeit steigt und es wird langsamer als ein einzelnes Insert.

Ergänzung (18. Dezember 2013)

Der Grund für db Wechsel (egal wohin):
Das du sonst den Vorteil von Json verlierst und der ist
ein Objekt der Freidefinierbar ist, so dass dieser gewechselt werden kann ohne das die DB neu angepasst werden muss.

Das würde vorraussetzen, dass er an dei Daten des JSON Objekts kommen muss. Muss er aber nicht, er muss es nur als ganzes in die DB schieben und wieder auslesen. _Falls_ das irgendwann mal ein Kriterium wird kann er ja immer noch das DBMS wechseln. Nur wegen des einen JSON Objekts gleich das DBMS zu wechseln halte ich für etwas übertrieben, zumal er dann den Rest seiner Anwendung auf das neue DBMS anpassen muss...

 

[alexander.klar]

Hallo som3,

falls ein DB-Wechsel für Dich vertretbar ist, schau Dir einfach mal den JSON-Support in der Oracle DB an, welcher demnächst verfügbar sein wird:

http://technology.amis.nl/2013/09/26/oow13-schema-less-data-management-using-sqljson/


Gruß,

Alexander


-------------------------------------------------------------------------------------------------------------------------
The views expressed on this site are my own and do not necessarily reflect the views of Oracle.

 

[som3]

Verstehe ich das richtig das ich bei einem DMS mit JSON Support die daten im JSON object selber direkt ber Query auslesen kann und nicht das gesamte JSON auslesen muss und in PHP verarbeiten muss?
Das ist zwar für mein Beispiel uninteressant aber damit ich einfach mal verstehe was mit JSON Support gemeint ist.

Und wieso es ein JSOS Objekt ist und kein "serialisierter Array / Object"
Dieses JSON kommt direkt vom der Google API das erstelle ich nicht selber.

Ich werde mir auf jeden fall mal MariaDB anschauen da es ja scheinbar wirklich um einiges Schneller ist.

@Alexander
​Oracle DB ist doch so ziemlich das selbe wie MySQL oder nicht?

 

[Daaron]

Verstehe ich das richtig das ich bei einem DMS mit JSON Support die daten im JSON object selber direkt ber Query auslesen kann und nicht das gesamte JSON auslesen muss und in PHP verarbeiten muss?

Wenn das DBMS entsprechend komplex gestrickt ist, ja.
MariaDB kann, nach genauerer Betrachtung, zwar die NoSQL-artigen Strukturen als JSON exportieren, aber (noch?) kein JSON importieren. Natürlich sind über die NoSQL-Daten verschiedene Queries möglich.
Der Knackpunkt ist: JSON-Strings können alle möglichen Datenstrukturen repräsentieren. In klassischem RDBMS, das alles in Tabellen, Spalten und verbundenen Keys organisiert, ist sowas wohl kaum machbar. Daher fließen bei PostgreSQL oder MariaDB eben etwas die Grenzen, es werden NoSQL-Ansätze für JSON verwendet.

Und wieso es ein JSOS Objekt ist und kein "serialisierter Array / Object"

JavaScript Object Notification
Effektiv ist JSON ein serialisiertes Objekt, aber die Form der Serialisierung ist recht speziell. Du kannst ja mal einen JSON-String mit der Ausgabe einer PHP-Serialisierung vergleichen. Es sieht einfach anders aus, ist inkompatibel.

​Oracle DB ist doch so ziemlich das selbe wie MySQL oder nicht?

OracleDB ist der Hauptgrund, warum Oracle die Entwicklung von MySQL verschleppt und Monty sich gezwungen sah, MariaDB zu schaffen. Kein Kartellwächter hätte auch nur im entferntesten ahnen können, dass Oracle viel lieber ihre proprietäre Lösung pushen, als den freien Liebling aller Webmaster zu füttern... Wäre ja völlig undenkbar... Was kommt als nächstes, darf Microsoft die Apache oder Mozilla Foundation aufkaufen?

OracleDB ist ein weitaus mächtigeres Gesamtkonstrukt als MySQL, eher ausgerichtet auf große Enterprise-Umgebungen.... und es kostet natürlich ne Kleinigkeit, und wenn ich mich recht erinner ist selbige Kleinigkeit recht groß.

 

[rIQ]

...und es kostet natürlich ne Kleinigkeit, und wenn ich mich recht erinner ist selbige Kleinigkeit recht groß.

Zwar etwas OFF-TOPIC aber:
Whats the difference between GOD and Larry Ellison?
GOD does NOT think he is Larry Ellison...

 

[AlbertLast]

Wenn das DBMS entsprechend komplex gestrickt ist, ja.
MariaDB kann, nach genauerer Betrachtung, zwar die NoSQL-artigen Strukturen als JSON exportieren, aber (noch?) kein JSON importieren. Natürlich sind über die NoSQL-Daten verschiedene Queries möglich.
Der Knackpunkt ist: JSON-Strings können alle möglichen Datenstrukturen repräsentieren. In klassischem RDBMS, das alles in Tabellen, Spalten und verbundenen Keys organisiert, ist sowas wohl kaum machbar. Daher fließen bei PostgreSQL oder MariaDB eben etwas die Grenzen, es werden NoSQL-Ansätze für JSON verwendet.

Dein halb wissen bei PostgreSQL ist zu mindestens falsch,
postgresql ist eine Objekt Orientierte Datenbank gewesen und hat daher schon vor seit vielen Jahren ~ 15 Jahren
NoSQL Fähigkeiten. Siehe HStore, Array und abgeleitet Tabellen.

Verstehe ich das richtig das ich bei einem DMS mit JSON Support die daten im JSON object selber direkt ber Query auslesen kann und nicht das gesamte JSON auslesen muss und in PHP verarbeiten muss?
Das ist zwar für mein Beispiel uninteressant aber damit ich einfach mal verstehe was mit JSON Support gemeint ist.

In PostgreSQL: ja

 

[Freezedevil]

Wenn es hier um den akademischen Gedanken geht und du in erster Linie was lernen willst, dann will ich mal nichts gesagt haben, aber wenn es dir vor allem um das Resultat geht, dann schau dir nochmal Post 9 an. Ich kann mir nicht vorstellen, dass du so viele Datensätze schreibst, dass es zu spürbaren Verzögerungen kommt.
Das Objekt einfach so wie es ist als String in die DB packen wird wohl die besten Ergebnisse erzielen, da man sonst beim Einfügen Zeit zum parsen des Objekts benötigt und beim Auslesen Zeit zum Joinen (unnötigerweise, da eh das ganze Objekt benötigt wird).

just my 2ct

 

[Fonce]

Dein halb wissen bei PostgreSQL ist zu mindestens falsch,
postgresql ist eine Objekt Orientierte Datenbank gewesen und hat daher schon vor seit vielen Jahren ~ 15 Jahren
NoSQL Fähigkeiten. Siehe HStore, Array und abgeleitet Tabellen.

Ähm objektrelational...

 

[Drexel]

Wenn Du viele Datensätze schnell einfügen willst beschäftige Dich mal mit Bulk Inserting. Die meisten Datenbanken habe da Vorgehensweisen für, ich habe es z.B. mal mit Oracle benutzt. Die Daten müssenndafür besonders aufbereitet werden und der Befehl entsprechend abgesetzt werden. Ist um ein vielfaches schneller als einfache Inserts. Aber ob das Dein Problem is k.A....

 

[Elcaro2011]

@[/COLOR]Alexander
​Oracle DB ist doch so ziemlich das selbe wie MySQL oder nicht?

MySQL wurde mit der Sun übernahme von Oracle "eingekauft". Die eigentlichen Oracle Datenbanken sind weitaus zuverlässiger, stabiler und sicherer.
Meinen Erfahrungen nach ist eine Oracle Datenbank in jeder Version der MySQL weit überlegen. Es lohnt sich über ein Wechsel zumindest nachzudenken.

Fröhliche Weihnachten!

 

[alexander.klar]

@<||><Som3><||>:
Sorry für die verspätete Antwort.
MySQL und Oracle DB beruhen auf unterschiedlicher Technologie (Sourcecode), wobei die Oracle DB mehr Möglichkeiten bietet als MySQL. Je nach Projektszenario kann natürlich auch der Einsatz einer MySQL-Datenbank Sinn machen. Ich habe aber noch nicht gehört, dass die für die Oracle DB angekündigten JSON-Funktionalitäten auch für MySQL verfügbar sein werden.

Alexander

-------------------------------------------------------------------------------------------------------------------------
The views expressed on this site are my own and do not necessarily reflect the views of Oracle.