I meant fixed length in the mainframe sense of records addressable (directly and only) by record number.
Fixed length records on PC's are (for the most part) only variable length bits of a stream that all happen (even by design) to be the same length. There is nothing to stop you from positioning the pointer to mid record before reading or writing, and completely corrupting the record structure in the process.
What's the reason for you frowny? Assuming your fixed-length records are delimited with newlines, you can just as easily process them as you would variable length records with the added bonus of being able to index you way directly to a given record. Even if they are not delimited, setting $/ = \80; or whatever the fixed length is, allows you to read them just as easily.
I don't see the problem?
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.
| [reply]
[d/l] |
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... :-)
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply]
[d/l] |
...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.
| [reply] |