>Hello all,
>
>I am brand new to MySQL. I have very limited experience with SQL type
>databases. MySQL appears to be a very elaborate product capable of many
>things. I've glanced at the documentation before writing this. I have 2
>very general question to all you 'experienced' MySQL users.
>
>Question #1)...
>
>My application is in definite need of an SQL database manager. That much I
>know. But what I'm looking for is a db manager that can handle backward
>compatibility (ie: database version independence) of my application's
>data.
>
>Putting it in laymen's terms...
>
>I have an application that creates and uses a database of data that it
>uses now (say with version 1.0 of my software). Next year I come out with
>version 2.0 of my software but I want my software to be capable of running
>with previous versions of data (stored in the database) as well as new
>versions.
>
>In other words, I want to develop my software to be backward compatible
>with previous versions of data. I know the application is my
>responsibility, BUT will MySQL be capable of managing concurrent versions
>of data inbetween software versions?
Sir, I can't figure out what you're asking. The DBMS handles the
data, and your application interfaces with the DBMS. If your app
changes but the DBMS doesn't, then the way the data is handled
doesn't change. The only thing that changes is the way your app
interfaces with the DBMS. MySQL is very good about backward
compatibility with older versions of itself; if you upgrade to a new
version of MySQL, there shouldn't be any need to rewrite your app.
>Questions #2)...
>
>I've used INFORMIX E/SQL in the past but only a little. So I am vaguely
>familiar with the 'style' of commands one must embed into the code to
>retrieve data from the database manager.
>
>Is there a 'standard' to SQL query command syntax? If I commit to MySQL
>today and decide to use ORACLE, INFORMIX, GNUSQL, etc. down the road (for
>whatever reason) will I have to rewrite my db interface handlers?
SQL is a standard maintained by a standards organization. No DBMS
vendor limits itself to this standard completely. MySQL is no better
or worse than any other RDBMS in this regard. You can avoid having to
rewrite your db interface by using ODBC or some other database
abstraction software. This limits you to the functionality supported
by ODBC, and makes your app run a little slower. You can also try to
limit your SQL statements to the basic SQL syntax shared by most
RDBMSs. This also limits your functionality, but speeds things up a
bit.
Depending on the developement language you're using, there may be
database abstraction software that allows more functionality and runs
faster than ODBC. For example, there are a number of abstraction
layers available for PHP.
>
>- - -
>
>Sorry about the simplicity of these questions but you can tell I am
>exploring what are my best options for introducing a db manager to my
>application without making costly mistakes from the start.
>
>Thank you
>Attila
Bob Hall
Know thyself? Absurd direction!
Bubbles bear no introspection. -Khushhal Khan Khatak
---------------------------------------------------------------------
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
