Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"SQLite is not designed to replace Oracle. It is designed to replace fopen()."

sqlite.org

Post reply on HN
Print view View original

41–50 of 58 posts

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#41

Post by derrickpetzold »

tomjen3 wrote: post #28
derrickpetzold wrote: post #21

Can anyone say when Oracle is justified? I have yet to encounter a problem the postgres or mysql didn't support but alas I have not worked on everything.

Support. You can properly find some solution to your issue with postgres online. Oracle can send an Oracle certified engineer who can solve your problem. Consistency. Your enterprise depends on terabytes of hyper valuable information (Wallmart with their sales data), can you guarantee that you won't end up with corruption issues? Or that the next version will work with your system too? That said as long as you make l…

InnoDB. I understand your support viewpoint but both of those dbs are opensource thereby leaving support open. From what I understand when the support comes into play is when you can sue the other party for not providing the service expected but there is company support for mysql and postgres so that still leaves me in the dark and I have never experienced corruption issues with either. Though my db experience is limited and I don't claim to be an expert.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#42

Post by nodata »

apl wrote: post #37
techtalsky wrote: post #7

Even though SQLite isn't designed to replace Oracle, I'm certain there's plenty of companies that have purchased expensive Oracle licenses for projects where SQLite would have worked perfectly well. I've often used it for web-based custom CMS's of one kind or another where many people would have used MySQL and the client would never know the difference. I'm sure many people have used Oracle for web-based internal too…

Regardless of how much fun lamenting the assumed technical incompetence of enterprise software development can be, I strongly doubt that this has ever happened. Oracle is very expensive, and SQLite is very limited outside its clearly delineated use cases. Oracle versus PostgreSQL or possibly MySQL -- maybe. But don't think Oracle sells snake juice; their reporting tools, for instance, are top-notch and way beyond wha…

I disagree with you completely.

I've worked places where there is a rule that "The Corporate Database is Oracle and Oracle Only". Any mention of database _at_all_ will mean someone will ensure that The Corporate Database is used. It doesn't matter if Postgres or SQLite would be a cheaper/better choice.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#43

Post by nhebb »

petercooper wrote: post #39
reduxredacted wrote: post #8

By the use of "an", I learned that I have been pronouncing SQLite wrong. The maintainers clearly prefer the spelling out of SQL in the title. I've always been on the "sequel" side of pronouncing SQL (hey, it's no worse than "scuzzy" for SCSI), which morphed SQLite into "Sequelite". I never realized how bizarre that sounded (almost more like a material than a database).

Just in case anyone cares because I did the research on this a few weeks ago (including watching its creator say it numerous times) it's S-Q-L-Lite. Yeah, that seems like a duplication of the L but there you have it.

I've always pronounced it that way in my head, which has lead to a few typos searching for "SQLlite" or coding up a "SQLliteConnection". If I'd just learned to pronounce it wrong I would have been typing it right all along.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#44

Post by StavrosK »

techtalsky wrote: post #38
apl wrote: post #37

Earlier quoted context omitted.

Regardless of how much fun lamenting the assumed technical incompetence of enterprise software development can be, I strongly doubt that this has ever happened. Oracle is very expensive, and SQLite is very limited outside its clearly delineated use cases. Oracle versus PostgreSQL or possibly MySQL -- maybe. But don't think Oracle sells snake juice; their reporting tools, for instance, are top-notch and way beyond wha…

Believe me, I wasn't trying to have fun at someone's expense. I think factors other than incompetence can account for this, like just simple ignorance. I was more speaking to how easy it is to underestimate SQLite's flexibility and power and not realize how wide its use case actually is. Of course for many use cases Oracle's tools are the best choice, but SQLite can handle quite a serious dataset in some use cases. A…

I worked with a thirty-million-row dataset for my thesis (after MongoDB famously choked and ate half my data more than once) with SQLite and it didn't bat an eyelid. It was fast as hell, too.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#45

Post by StavrosK »

derrickpetzold wrote: post #41
tomjen3 wrote: post #28

Earlier quoted context omitted.

Support. You can properly find some solution to your issue with postgres online. Oracle can send an Oracle certified engineer who can solve your problem. Consistency. Your enterprise depends on terabytes of hyper valuable information (Wallmart with their sales data), can you guarantee that you won't end up with corruption issues? Or that the next version will work with your system too? That said as long as you make l…

InnoDB. I understand your support viewpoint but both of those dbs are opensource thereby leaving support open. From what I understand when the support comes into play is when you can sue the other party for not providing the service expected but there is company support for mysql and postgres so that still leaves me in the dark and I have never experienced corruption issues with either. Though my db experience is lim…

I had experienced db corruption with MySQL years ago, when the disk became full. To be fair, I think it was MyISAM.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#46

Post by StavrosK »

kelnos wrote: post #24
reduxredacted wrote: post #8

By the use of "an", I learned that I have been pronouncing SQLite wrong. The maintainers clearly prefer the spelling out of SQL in the title. I've always been on the "sequel" side of pronouncing SQL (hey, it's no worse than "scuzzy" for SCSI), which morphed SQLite into "Sequelite". I never realized how bizarre that sounded (almost more like a material than a database).

I and most people I know call it "sequelite". That works for me...

Esquelite sounds pretty good too...

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#47

Post by StavrosK »

ebzlo wrote: post #13
reduxredacted wrote: post #8

By the use of "an", I learned that I have been pronouncing SQLite wrong. The maintainers clearly prefer the spelling out of SQL in the title. I've always been on the "sequel" side of pronouncing SQL (hey, it's no worse than "scuzzy" for SCSI), which morphed SQLite into "Sequelite". I never realized how bizarre that sounded (almost more like a material than a database).

So does that become S-Q-L-ite or S-Q-Lite, you think?

I say S-Q-L-ite.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#48

Post by wheels »

StavrosK wrote: post #44
techtalsky wrote: post #38

Earlier quoted context omitted.

Believe me, I wasn't trying to have fun at someone's expense. I think factors other than incompetence can account for this, like just simple ignorance. I was more speaking to how easy it is to underestimate SQLite's flexibility and power and not realize how wide its use case actually is. Of course for many use cases Oracle's tools are the best choice, but SQLite can handle quite a serious dataset in some use cases. A…

I worked with a thirty-million-row dataset for my thesis (after MongoDB famously choked and ate half my data more than once) with SQLite and it didn't bat an eyelid. It was fast as hell, too.

Size isn't the problem with SQLite databases. It's that it's unbearably slow with even fairly trivial joins and most of the other operations where it'd make sense to actually have an SQL database. SQLite is fine for tabular data, but then, so are a bazillion other things. Basically it's the perfect SQL database for the times that you shouldn't be using an SQL database.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#49

Post by diminish »

larrik wrote: post #2

I first used SQLite because I thought (in C++) "Man, instead of writing crazy datastructures, I wish I could just use SQL on a spot in memory" SQLite came up in my Google search, and ta da! Of course, this was back in 2003 or so, and that project never turned into anything more than a fancy wrapper over SQLite and Lua. Still, SQLite == awesome, when it is appropriate.

SQlite is a gem; when we develop web sites for clients, we first try to use sqlite, and if not we use MySQL and PostGres; we only use mssql, oracle when the customer has already a legacy database. What about you?

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#50

Post by tluyben2 »

nodata wrote: post #42
apl wrote: post #37

Earlier quoted context omitted.

Regardless of how much fun lamenting the assumed technical incompetence of enterprise software development can be, I strongly doubt that this has ever happened. Oracle is very expensive, and SQLite is very limited outside its clearly delineated use cases. Oracle versus PostgreSQL or possibly MySQL -- maybe. But don't think Oracle sells snake juice; their reporting tools, for instance, are top-notch and way beyond wha…

I disagree with you completely. I've worked places where there is a rule that "The Corporate Database is Oracle and Oracle Only". Any mention of database _at_all_ will mean someone will ensure that The Corporate Database is used. It doesn't matter if Postgres or SQLite would be a cheaper/better choice.

I'm seeing this too ; the choice is company-wide, the licenses are bought company wide. And yes it would save money in many departmental apps; no-one seems to care.
Post reply on HN