I mean no offense to anyone but the conversation on this subject seems a little strange to me.
SQLite is what it is. If it was like everything/anything else, we wouldn't need or want it. It is designed to fill a particular niche in the DBMS world and from my perspective, with every passing day, it seems to be filling it a little better. Concerning SQLite's extensions, they are what they are - as conceived by DRH and his assistants. They have a particular vision for this product and they are continuing to realize it with every new release. If you want another DBMS, they're out there. If you want what SQLite has to offer, it's available. To me, it's mostly a black and white subject. I can understand people requesting and suggesting new features and functionality. That's normal and appropriate. But, I can't see those that dramatically alter the functionality, complexity, size, or paradigm of the product being implemented, or ask those that ask it to be like some other DBMS. I guess I'm old school when it comes to databases. To me, they are highly efficient file data storage and retrieval mechanisms. All the other bells and whistles my employer wants go into a traditional 3-tier software structure. The middle tier is the exclusive home of the business rules. I wouldn't consider migrating those into the database or DBMS. Doing so spreads them out and makes cohesive control and support of them much more difficult. Where I work, our software is responsible for all data qualifications, data manipulations, the maintenance of referential integrity, and the control of access in a multi-threaded environment. I wouldn't even consider asking the DBMS to do those things. As a developer, I want explicit control of them and other functionalities that are not strictly database (file cabinet) related. My only unfulfilled desire is that SQLite eventually be fully ANSI SQL '92 compliant, as a minimum. From my perspective, it is getting there. Rome wasn't built in a day. My 2 cents, Lee Crain _______________________ -----Original Message----- From: alex katebi [mailto:[EMAIL PROTECTED] Sent: Friday, January 11, 2008 1:21 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] SQLite --> PostGres I don't think many people have your problem. I mean using Sqlite towards using PostGres. Please let's not pollute Sqlite. Thanks, Alex Katebi ----- Original Message ---- From: P Kishor <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Friday, January 11, 2008 2:19:23 PM Subject: [sqlite] SQLite --> PostGres I have been writing an app using SQLite (great to develop with, and to serve with to an extent), always with the intent of one day upsizing it to PostGres (pain in the tush to develop with, but great to serve with to any extent). Much to my delight, I am finding that y'all (the SQLite developers) have made many things (for example, datatypes) similar to PostGres (yes, I know most all about how SQLite datatypes). My question -- why not take it all the way, and make SQLite almost a mini-PostGres... wait, before you chide me -- I don't mean in the "add more features" way, but in the "make syntax and datatypes as similar as possible" way. For example, why have the "INTEGER PRIMARY KEY" when it could just as easily be called "SERIAL"? One way might be to allow for aliases -- so, SERIAL would mean the same as INTEGER PRIMARY KEY, or CHAR(3) would mean the same as TEXT with a CHECK CONSTRAINT, and so on. Wouldn't that increase the already wildly popular appeal of SQLite even more so without subtracting or weighing anything down? By the way, I didn't find a BLOB kind in PostGres -- is that the same as BYTEA? If yes, that would be another candidate for such an alias. -- Puneet Kishor -------------------------------------------------------------------------- --- To unsubscribe, send email to [EMAIL PROTECTED] -------------------------------------------------------------------------- --- __________________________________________________________________________ __________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
