Re: transactional file persistence?
- From: Sabine Dinis Blochberger <no.spam@xxxxxxxxxxxx>
- Date: Thu, 13 Nov 2008 09:55:55 GMT
Tommy Halsbrekk wrote:
Lew wrote:
Tommy Halsbrekk wrote:
indexes and miscellaneous resource management components. Any of which
increase the complexity and can fail for a number of reasons.
Red herring. Well designed DBMSes have that covered.
So by your definitions, databases do not ever fail?
These days, data corruption in a RDBMS only occurs due to user error,
like messing with system tables directly, making a file based backup
while it's still running etc.
Its a use case with requirements for an entirely different use than aNo, but it does suggest itself, since your requirements sound very much
db. Just because it requires transaction support does not mean the only
solution is a db.
like one. Why not look into it some more, but you seem to be hostile
towards the idea.
- one solution is easier to fix than the other.Some RDBMS, like Berkeley, are quite "simple" IMO. Subversion uses it,
- one solution requires less expert knowledge to fix than the other.
- one solution has less components that can fail than the other
and the file system wins in all of these cases for my requirement.
So the conclusion is if one does not need a structured data store, then
dont use a db.
and it does not seem to have much overhead at all.
But, if you say this, I don't get why you asked "for ideas". You have
made up your mind, so run with it. We won't stop you. ;)
Not at all. But you did ask for ideas.It is fairly common for a db to have some sort of problem, which
prohibits completion of the operation. It is not very common for a
filesystem to experience the same level or complexity of problems. The
You are wrong. Filesystems are notoriously unreliable for transactional
operations. DBMSes, the good ones, have all kinds of safeguards and
features to support data integrity and durability. Advantage: DBMS.
Are there any reason I cant make use of any of these safeguards in the
solution I make, without using a db? or is that prohibited for some reason?
I know that what you are trying to say is that I should use off theIt all depends on the situation of the project. Sometimes, it
shelf components, because its tested and works.
You might want to re-visit your engineering text books, specifically the
chapters about adapting your solution to the actual requirements. Using
a sledgehammer to kill a bee is not the solution to the problem I am
trying to solve.
compensated adapting the sledgehammer instead of constructing one
yourself. Textbooks are often not very close to real world scenarios.
YMMV.
And don't kill bees. We need them for food (polonization). <g>
.
- Follow-Ups:
- Re: transactional file persistence?
- From: Tommy Halsbrekk
- Re: transactional file persistence?
- References:
- transactional file persistence?
- From: Tommy Halsbrekk
- Re: transactional file persistence?
- From: Sabine Dinis Blochberger
- Re: transactional file persistence?
- From: Lew
- Re: transactional file persistence?
- From: Tommy Halsbrekk
- Re: transactional file persistence?
- From: Lew
- Re: transactional file persistence?
- From: Tommy Halsbrekk
- transactional file persistence?
- Prev by Date: Re: transactional file persistence?
- Next by Date: Re: transactional file persistence?
- Previous by thread: Re: transactional file persistence?
- Next by thread: Re: transactional file persistence?
- Index(es):
Relevant Pages
|