4 ms·
> SQL has no ability to express relexation of the ACID principles. If you're streaming weather data into a SQL database, it could be ok to drop inserts here and
by jimktrains2 12y ago
> SQL has no ability to express relexation of the ACID principles. If you're streaming weather data into a SQL database, it could be ok to drop inserts here and there to gain throughput for the data analysis operations. SQL has no abilities to express such a thing (except in db-specific hacks).
Why should the language control the underlying data store to that level? Also, SQL itself is not defined by or defines ACID principles. You can (and some people do) run SQL over very non-ACID databases (everyone using MyISAM or SQLite?)
I personally feel that tying the data-store so close to the query language is a recipe for unneeded complexity. Though, the transaction isolation levels may be close to what you're talking about (though, I don't think there is anyway to tell a db like PostgreSQL "Go ahead, lose this. I don't care about it".)
> SQL is superficially simple, but at scale the simplicity is a lie. Thhe performance trade-offs you make require you to understand the internals of the database you're running on and how it interprets the query, and often you feel like you're dealing with a too high level API. Often you're resigned to "tricks" to force the engine to do the right thing, like optimizer hints, special index types or denormalized data.
Please tell me of anything where it isn't true that the more intimately you know your tools the better you can use them. Quite honestly most query planners are really friggin' good at what they do (just like a compiler, or are you a person that still claims hand tune assembly is the answer to everything).
EDIT: PostgreSQL does allow unlogged tables that are not crash safe, though I don't think they're randomly lose rows, but are faster. So there are some semantics that allow you to control that, but they are probably vendor-specific (getting into my complexity argument). Thanks Myon on #postgresql for pointing that out.
- AlterEgo20 12y agoThere is Asynchronous Commit feature in postgres, that allows you to gain performance by allowing postgres to lose some commited transactions. It can be controlled on transaction level and is exactly :"Go ahead, lose this. I don't care about it". Manual: http://www.postgresql.org/docs/current/static/wal-async-commit.html http://www.postgresql.org/docs/current/static/wal-async-comm...
- jimktrains2 12y agoLike an unlogged table that's only not crash safe. I think GP was talking about rows actually not being written to the db during normal circumstances. Maybe I'm misunderstanding what GP is asking for.
- AlterEgo20 12y agoHm. "rows actually not being written to the db during normal circumstances". A database that acts like /dev/null ? Like BLACKHOLE MySQL storage engine? I can not imagine a real use case, where it will be needed. If you allow a database to lose "some" rows it may well lose all of them. What is the purpose of a database that does not store your data?
- jimktrains2 12y agoI'm not the one who said "If you're streaming weather data into a SQL database, it could be ok to drop inserts here and there to gain throughput for the data analysis operations. SQL has no abilities to express such a thing (except in db-specific hacks)." I can understand wanting an unlogged table for the speedup (missing the last sec of weather data won't cause huge problems and I'm more forgiving of missing data when a whole machine fails), but just to be able to randomly drop things seems scary. Also, I thought you were joking, but you're not http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-eng... bu