I have to deal with fixed length records an awful lot. Yes, they have advantages, but frankly IMO their limitations outweigh them. They scale poorly (actually, by definition, not at all) and are usually wasteful of space. And to boot are often mandated by inferior programmers who think they are making their lives easy but are in fact making them more complicated. (Hows this: fixed length records on variable length lines, with 70% wasted space. Blech.)

Anyway, never mind me, just grumbling... :-)

...often mandated by inferior programmers....

Ouch! I can feel the wrath of a zillion mainframe programmers aiming lightening bolts in your general direction...or was that private parts? :)

Funny thing is, if your filesystem supports transparent compression (as many mainframe file subsystems, and even my PC do), the "wasted space" per record amounts to 2 or 3 physical bytes per record in many cases. A filler byte plus a repetition count. Remove the need for a record separator and your almost at a status quo. Removing the need for field separators and your often into into positive ground.

Add the fact that you don't have to parse to find the fields and the performance can be a vast improvement over CSV and the like, never mind XML

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.

The big problem with fixed-length records IMO is that real-world data will always find ways to be longer than the fixed length.

---

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

Actually I'm not real sure if I agree with you here. The arguments you have made don't gibe with my understanding of fixed width, and non fixed width. If the filesystem is doing transparent compression, then the file system is in fact a stream and you are adding a layer of work (no doubt handled by subsidary controllers or whatnot) to then represent the data at a logical fixed width format. Presumably if someone thought the cycles weren't worth wasting doing CSV handling (or XML for that matter) they could also offload the task to subsidiary hardware, and we are back at point one, which is that fixed width records dont scale well. :-) The only argument left for fixed width records is they dont care what value is within them, but this also goes for at least one form of delimited files (length delimited fields) which also scale well.

BTW, im not saying that fixed width doesnt suit some circumstances. Just that I dont think those circumstances are really that common. (These days. :-)


---
demerphq



First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi