On 9/11/06, Marty <[EMAIL PROTECTED]> wrote: > In all seriousness, the information you present here is great, and > much appreciated. Your sarcastic, condescending tone kind of gets in > the way of the message, though.
Sarcastic, perhaps. Condesceding, I think not. It is ridiculous that people can simply say whatever they want to about software they've taken little time to learn. I did not see one single post by mensanator to the SQLite mailing list, or by anyone else on this thread who criticized SQLite. Rather, it was SQLite is just crappy, or not a database, or not an SQL database, or other expletives. And while mensanator had other claims about Python's documentation, this general frustration then carelessly took a turn to SQLite. And as for the alleged problems in SQLite, there was (to my estimation) much less effort expended in finding a solution than there was in badmouthing an otherwise wonderful piece of software. If you are too impatient to read the documentation, fine. If you don't want to consult the experienced people on the SQLite mailing list (who are glad to help), fine. But DON'T remain willfully ignorant AND blame SQLite for not working the way your intuition demands. For years I've watched people badmouth SQLite whose claims are uninformed, unfounded, or downright unfair. Had a single accuser here posted this alleged problem with SQLite to the SQLite mailing list, I probably would have remained silent here (and answered it more politely there). > And here is the crux of the issue. Sqlite doesn't follow the standard > for sql. The name certainly implies that it would. This doesn't make > it a crappy product, but it is certainly misleading. Newsflash: No database follows the complete SQL standard, not even Oracle. By the logic in this thread, there is no such thing as an SQL database. > I must admit, that after 10 years of oracle experience, I don't necessarily > read all > of the documentation for a new dbms I'm trying out, particularly a > light weigth variety. I get in, and try things. Sometimes I get > bitten, but I learn better that way. I would hope then that when you don't read the documentation, and you get bitten, you know better than to blame the software. > I would expect, however, for each > product with 'sql' in the name, to, at least by default, adhere to the > standard. And expectations are what set this conversation up. These expectations are simply unrealistic. If someone is simply too lazy to read the documentation or use the mailing list, then they can only blame themselves. And if you say SQLite misrepresents itself, then what do you say about MySQL, which until version 5 didn't have views or triggers? In fact, it didn't even have subselects until version 4. For a period of years, SQLite had more mainstream SQL features than MySQL. Yet you don't see people going around claiming that MySQL is not an SQL database -- that it's misrepresenting itself. So no, SQLite most certainly does not misrepresent itself. It is an open source, embedded, relational database that uses SQL as its query language. Plain and simple. Just because it may not implement part of the standard you or someone else likes does not strip it being an SQL database. > But, I don't expect that anything productive will come from the rest > of this thread. Your post had the stink of zealotry all over it, and > we all know what happens when a zealots favorite is questioned. Expecting people to get the facts before badmouthing something is hardly zealotry. I am tired of seeing SQLite taking the blame when certain people choose simply to assume rather than read (or consult others). They see database-level locking, they ASSUME it's too slow for any kind of write concurrency applications. They see type affinity, they ASSUME it's just substandard or useless, and then by further soritical leaps, discount it as even an SQL database? Rather than reading, or testing, or asking people who know, they get frustrated and go straight to blaming it. That is completely unfair. The purpose of this post is to demonstrate that: 1. SQLite was not at fault here, nor insufficient for the purpose stated. 2. There are people who can easily provide the very help you need, provided you ask them, and try to keep your derogatory comments to a minimum. 3. There is no substitute for reading the documentation and learning the product. This is doubly true of relational databases. I'd love to see someone who uses MSSQL or Oracle try to install and use PostgreSQL or Firebird with nothing but instinct. I currently use three of these databases in production, and I couldn't survive without reading documentation. > Again, thanks for the info. It'll serve me well when I'm playing with > sqlite later. You are more than welcome. Glad to help. -- http://mail.python.org/mailman/listinfo/python-list
