From: | Lincoln Yeoh <lylyeoh(at)mecomb(dot)com> |
---|---|
To: | "Manuel Lemos" <mlemos(at)acm(dot)org>, "Thomas Good" <tomg(at)admin(dot)nrnet(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Connecting website with SQL-database..... |
Date: | 2000-04-20 02:59:07 |
Message-ID: | 3.0.5.32.20000420105907.008fb830@pop.mecomb.po.my |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-interfaces pgsql-sql |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Lincoln Yeoh | 2000-04-20 03:13:28 | Repairing stuff when broken. |
Previous Message | Hentosh | 2000-04-20 02:50:01 | Full text indexing. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-04-20 03:14:13 | Re: How do I select nth row from a table |
Previous Message | ganesanm | 2000-04-19 21:18:01 | How do I select nth row from a table |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-04-20 03:47:08 | Re: Recursive SQL |
Previous Message | Tom Lane | 2000-04-20 02:50:24 | Re: Counting distinct names |