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:
http://solutions.mysql.com/solutions/?type=29
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.
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!
Database questions? Check the forum:
http://www.databasedevelopmentforum.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
