Les restrictions au niveau des sous-requêtes semblent encore d'actualité. Il me semble avoir été mordu soit par le problème des sous-requêtes référençant une table en écriture, soit par la restriction sur les requêtes corrélées (avant la version 8.0.14).
La taille maximum d'une ligne est de 64Ko, et donc un varchar ne pourra pas aller au delà. Pour y mettre du texte plus gros, il est possible d'utiliser les types BLOB et TEXT, qui ont certaines restrictions, et qui se chargent différemment d'un varchar dans l'API ODBC.
MySQL ne connait pas le "CREATE SEQUENCE". L'on peut avoir des colonnes auto-incrémentées, mais on perd le côté universel de la séquence.
J'ai également cru comprendre que le planificateur de requêtes de MySQL s’essouffle bien plus rapidement lorsque le nombre de jointures et la complexité des requêtes augmentent, mais je n'ai pas de benchmark sous la main.
Aucune de ces restrictions n'est complètement bloquante et l'on peut toujours émuler quelque chose, mais le schéma que je migrais était complexe, et Postgres était simplement un outil plus adapté à mon problème.
[^] # Re: Mysql a(vait) du retard. Est-ce toujours le cas ?
Posté par small_duck (site web personnel) . En réponse au journal Postgresql, un retour d'expérience. Évalué à 10.
Les restrictions au niveau des sous-requêtes semblent encore d'actualité. Il me semble avoir été mordu soit par le problème des sous-requêtes référençant une table en écriture, soit par la restriction sur les requêtes corrélées (avant la version 8.0.14).
La taille maximum d'une ligne est de 64Ko, et donc un varchar ne pourra pas aller au delà. Pour y mettre du texte plus gros, il est possible d'utiliser les types BLOB et TEXT, qui ont certaines restrictions, et qui se chargent différemment d'un varchar dans l'API ODBC.
MySQL ne connait pas le "CREATE SEQUENCE". L'on peut avoir des colonnes auto-incrémentées, mais on perd le côté universel de la séquence.
J'ai également cru comprendre que le planificateur de requêtes de MySQL s’essouffle bien plus rapidement lorsque le nombre de jointures et la complexité des requêtes augmentent, mais je n'ai pas de benchmark sous la main.
Aucune de ces restrictions n'est complètement bloquante et l'on peut toujours émuler quelque chose, mais le schéma que je migrais était complexe, et Postgres était simplement un outil plus adapté à mon problème.