[snip a lot...] MySQL alone cannot represent a complex data-structure. [/snip]
Incorrect, and if it IS the case (from your POV) then no RDBMS can represent a complex data structure. [snip] Re-modeling of MySQL data is required in Perl, PHP, Java, etc. In each language - I have had to re-model the entire MySQL data stucture in that programming language. [/snip] Define re-modeling, succinctly. [snip] MySQL needs to have the ability to add properties to columns and tables. [/snip] No other RDBMS have this, do they? [snip] If I change one column, add one field, play with one table... I have to go into all of that code in all of those languages and mess with either how the front-ends and/or how the back-ends are interpreting the data-schema. [/snip] No you don't "have to". The application will continue to work normally unless you do something funny to the database structure itself. To consider the additional data you have to make changes. Frequent changes of the underlying data model means that it is not designed for the purpose properly from the beginning due to a lack of proper analysis. [snip] ------------------------------------------------- OBJECTIVE ------------------------------------------------- To get MySQL to be the one, central data-source for nearly everything used in your applications and data-interfaces. Not just data...->Dynamic data. No more manual SQL statements in your applications.->Dynamic SQL. Removing a single column from one of your MySQL reports would be as simple as doing this: * mysql> UPDATE myTable.myColumn SET isVisible=FALSE; It doesn't matter what programming language the report is programmed in - that column would no longer show up in the report. [/snip] I can programmatically make the report aware of column existence now, using other standard mechanisms that have been used for years. [snip] Or change what name is displayed for your column name in all your MySQL reports? * mysql> UPDATE myTable.myColumn SET Alias='My Display Name'; [/snip] mysql SELECT myTable.myColumn AS "My Display Name" [snip] You could do the same by just editing the SQL statements of your Perl, PHP, Java, etc. application, easy... RIGHT? [/snip] You're right! [snip] ----------------------------------------- YOUR POINT ? ----------------------------------------- [/snip] [snip] Instead of SQL code in your applications, automatically generated SQL. [/snip] A mind-reading application? Automatically generated how? [snip] Instead of editing programming language code... a simple SQL statement from the MySQL shell [/snip] Do you mean a non-automatically generated SQL statement from the MySQL shell. [snip] Forcing for the existance of every database to contain two tables named TABLES and COLUMNS ? This solution is already being used by some. [/snip] And anyone with reasonable knowledge of a programming language can do this too. But I think it misses the point. Are you proposing something beyond Cobb's rules for RDBMS? If so it does not specifically affect MySQL, but you want it to because it is the database you use, right? [snip] The only possible downfall to this approach is that for any properties we wish to assign to a column - we must add to all columns. So, even though a property may only apply to a couple columns in a particular table, it would be a property for every column in every table, although it might not need to actually be defined (could be left NULL). [/snip] I love conundrums, don't you? [snip] * There needs to be a standard. I'm talking about every interface ever devised for MySQL, not just HTML formatting. After all, it's all about interfaces, is it not? MySQL holds the data - but the data means nothing unless it can be viewed, added, and edited -- hence an interface. [/snip] Given the depth and breadth of the proposed ideas I will have to say, as said before, that you are talking about RDBMS in general. Applying such a set of "standards" to one product is not a standard at all...just a manufacturer's feature set. [snip] * If we can make MySQL more flexible - we can make our data interfaces more flexible. [/snip] So the interfaces I design are not as flexible as I have thought? PHPMYADMIN is not flexible? Your interfaces aren't flexible? [snip] Am I missing something here that all other programmers are using? Am I embarassing myself as some intermediate programmer? Perhaps... but in my humble opinion and in light of what I've been exposed to, I feel there is a significant need for dynamic schema properties or something very similar. [/snip] Ryan, it is nice to see such youthful exhuberance! But I would like to know what your experience is with designing interfaces, what your seperate experience is using databases (design, extraction, etc.). While you have some nice points most (if not all) have been achieved at some level. However let's take one property combined with your TABLES and COLUMNS idea.... >mysql UPDATE column.This SET isVisible=FALSE; I need to diplay that column in one report and not in another. How is that gonna work? Right now I can query any or all columns and programatically make a decision (quickly) whether to display or not. I can count and return only the columns in the recordset, I can traverse the sets up and down, left to right, and back again. And it's not hard. And if I change the table under the application it does not effect the application's operation. Interesting thoughts Ryan, and if my stuff seemed toungue-in-cheek...it is! :) It's Friday! Jay --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php