>25. Each table can have a different storage backend (”storage engine”).
>Yes, we absolutely allow this.
>Each engine brings a certain strength to the storage and retrieval
>solutions you can create with MySQL. We explicitly recognize that there is
>no "one size fits all" approach that meets the needs of every problem. This
>also allows for special-purpose solutions to be integrated into MySQL:
Actually, this is one thing that annoys me too, or actually, that not
everything is supported in every storage engine. You get, for example,
full text indices, but no transactions. And so on.
>38. The number of joins per query is limited to 61.
>True, but why is this a problem? Do you frequently (or ever) need to join
>more than 61 tables into the same query? If you do, I propose that you need
>to revisit your schema design choices or review how you write your queries.
>In this case, I think we are discouraging bad practices.
Bad practices? So, if you have too many joins, your schema design
is wrong? This is just silly... if your data is split over different tables
it's usually because it's normalized, and especially for more complex
applications this is a "pro", not a "con".
>49. There are no sequences.
>Please explain why auto_increment cannot meet this same need? Why have the
>overhead of two ways of performing essentially the same function? This is
>just one less way to confuse your design.
Sequences are way easier to use in multi-table inserts.
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!
Database questions? Check the forum: