Re: Connecting website with SQL-database..... - Mailing list pgsql-general
From | Lincoln Yeoh |
---|---|
Subject | Re: Connecting website with SQL-database..... |
Date | |
Msg-id | 3.0.5.32.20000420105907.008fb830@pop.mecomb.po.my Whole thread Raw |
In response to | Re: Connecting website with SQL-database..... ("Manuel Lemos" <mlemos@acm.org>) |
Responses |
Re: Connecting website with SQL-database.....
|
List | pgsql-general |
At 03:39 PM 18-04-2000 -0200, Manuel Lemos wrote: >I may be mistaken, but the last time that I looked at Perl DBI, it didn't >seem to a complete database abstraction layer than it is needed. For >instance, you want retrieve data from date fields the results come >formatted in a database dependent way. This means that your DBI >applications can't really be that much database independent as you still >have to handle datatype differences in the application code. > I wish you all the best. And there's a chance you may succeed (tho it looks real slim from here). I may be wrong but don't see much hope of you succeeding without chopping off miscellaneous database specific features which make some people choose to use those various databases in the first place. If you put those features in, then you'll be back to square one, the apps have to deal with them. And maybe some bright spark will come up with an abstraction layer between Metabase and the app, just to remove them and the trouble of dealing with them :). The reason why we're in this mess is because the database people insist on it being so, and maybe there are good reasons for them to insist on it. Then there are things like datafield lengths and limits. I prefer them to be handled by the app, rather than the database buffer overflowing on them, truncating without warning or something. But there's still hope as not everyone needs those features. I haven't needed DECODE for instance, haven't used the built in programming languages, nor much trigger stuff. I think perl DBI took the pragmatic approach, well in the spirit of Perl's more than one way to do it. Messy, but works rather well. The DBI Proxy thingy was a real saver for one of my friends. >With this Metabase package in PHP date fields are always returned formatted >in the industry standard ISO 3166 (YYYY-MM-DD HH:MI:SS). Then you do >whatever processing you want with dates formatted this way, but it's always >DBMS independent. OK this one is nice. Is there also a standard for timezones and finer than one second resolution? Transactions for MySQL would be interesting to see. Plus some people seem to want Postsgresql to do transactions Oracle style, whereas some might want Oracle to do transactions Postgresql style. So how about Metabase helping out? I think if you can put in direct non ODBC support for DB2 and Oracle you could have a much bigger market for your stuff. Then maybe we could move apps seamlessly among Postgresql, DB2, Oracle environments. You'll probably end up with a lot of work just keeping up with changes and developments though. Good luck! Cheerio, Link.
pgsql-general by date: