Delicious flat che^H^H^Hfiles (30)

1 Name: #!/usr/bin/anonymous : 2006-12-02 10:33 ID:SeI56d3E

I was wondering, does anyone here have anything interesting to say about flat files for data storage ? Recommended reading, tips, tricks and advanced concepts...

You see, I'm not a big fan of relational databases. I do understand them very well, actually I pay my bills by working on a quite big database application, it's just that I like the simplicity and beauty of flat files. And real men don't need DBMS anyway. OK, let's not talk about RDBMS.

Say, which markup language / data serialization format do you like ? Have you used xattrs in any project ?

18 Name: #!/usr/bin/anonymous : 2006-12-06 03:41 ID:Heaven

>>9-17
Guns kill people.
No, people kill people.

19 Name: #!/usr/bin/anonymous : 2006-12-06 04:32 ID:Heaven

>>18

Don't start that "Oh no! ARGUMENT on the INTERNET!" shit. This isn't and argument that has been done to death, and it is entirely civil and well-reasoned.

Don't make a mockery of human discourse, man.

20 Name: #!/usr/bin/anonymous : 2006-12-06 08:12 ID:Heaven

>>19
That's just what Hitler would've said!

21 Name: #!/usr/bin/anonymous : 2006-12-06 10:33 ID:Heaven

I cant believe you people are actually discussing this. It makes no sense ! Do you seriously believe that it is better to make bad decisions, because good ones will allow you to add more features ?

Look, I'm not saying that every design should be perfect. If you really understand what you're doing, then there's nothing wrong with breaking the rules in the name of simpler/faster software ( which is the case here ).

22 Name: #!/usr/bin/anonymous : 2006-12-06 13:07 ID:Heaven

>>21

Maybe you are familiar with the gambit of playing Devil's Advocate?

But also, note how your own argument pre-supposes that modularization and abstraction is a good decision, and then argues that you should do this because it is a good decision. You are begging the question there.

This idea is very deeply ingrained in software developers. I am merely throwing out the suggestion here that maybe that isn't always the case.

23 Name: #!/usr/bin/anonymous : 2006-12-06 21:49 ID:oUxukLrR

I dunno. I tend to think if you lack discipline enough, you'll find a useless feature you can add instead of real work, regardless of how modular your code is or isn't. My own experience bloating up really messy FSMs attests to this.

24 Name: #!/usr/bin/anonymous : 2006-12-06 22:31 ID:Heaven

>>23

You code Flying Spaghetti Monsters? That's awesome.

Er, seriously though, you could argue that if it was hard enough to add those useless features, you would prefer to do the real work instead.

25 Name: #!/usr/bin/anonymous : 2006-12-07 01:55 ID:Heaven

[FSM means Finite State Machine.]

Wouldn't the real work be harder too?

26 Name: #!/usr/bin/anonymous : 2006-12-30 17:30 ID:Heaven

Delicious flat Guevara?

27 Name: #!/usr/bin/anonymous : 2007-01-02 08:31 ID:Heaven

Did someone mention Godwin's law yet?

28 Name: #!/usr/bin/anonymous : 2007-01-07 00:36 ID:Heaven

Saying modular design promotes feature bloat is like saying clean code and indentation promote feature bloat. The link is there if you squint hard enough, but it's sketchy at best.

Modular design may lead to a runtime performance hit, if it isn't automatically optimized out.

29 Name: #!/usr/bin/anonymous : 2007-01-12 02:33 ID:2YIGLePE

Database recoverability is much, much superior to filesystem recoverability. So at the very least, store your xml files in an RDB.

30 Name: #!/usr/bin/anonymous : 2007-01-12 23:15 ID:Heaven

>>29
And access the RDB with CORBA. Your methods should be wrapped at least five deep, or it won't be Enterprise and Scalable.

This thread has been closed. You cannot post in this thread any longer.