[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
