On Tue, 4 Apr 2006, Arí Ricardo Ody wrote:
> At 14:03 4/4/2006, you wrote: > > If you want to make your database available for multiple languages, you > > should taken that into account when you're designing it. Or you should > > use some code. > > No offense, but in front of DB2 database (as Oracle, Sql Server, etc.) Neither SQL Server nor Oracle have this data type AFAIK. TIMESTAMP on interbase has a precision of 5 digits. TIMESTAMP on MySQL has a precision of 0 digits. TIMESTAMP on MS-Access has a precision of 3 digits. Actually, TDateTime is based on the TDateTime type of MS-Windows, used in MS-Access... > languages that must adapt themselves... They(the databases) has thousands of > installed copies and run in thousands of firms around the world. You can reverse this argument: The database should adapt itself to the tools. Who will use a database that no tool supports ?? The tool comes first, then the database. You can argue about this a lot; there is no end. The truth of the matter is that general-purpose languages never can support all database native types. For example: MySQL supports an enumeration type. MySQL is probably much more widespread than DB2, oracle and SQL Server put together. (if you count installed servers) Yet no language has support for the enumerated type of MySQL... What is more: there are standards: SQL does not define the precision of TIMESTAMP. Most programming languages adapt to standards, for good reason: there would be no end to the number of custom types you would need to define if there were no standards. Also, to avoid vendor lock-in, most databases are designed so they can be migrated from one server to another. You cannot do that if you use data types which only exist on one kind of server... To cut a long story short: stick to some standards. If some types fall outside of the standards: too bad. This is the price you pay for using exotic datatypes. Michael.
