If you follow shuch a scheme, you will have to keep your internal data in lockstep with your stored data structure. Choose one as master and let the other slave to it (always sticking to this heirarchy). Either way, you will have to navigate some form of object tree... And translate that out to the other half of your memory/storage scheme. People using xtalk talk about tables and arrays alot cause these are so much easier than ontologies. Even a relational data structure is easier than a true object scheme as it is more hyper-linking than object inheritence (pointers without a seporate schema as formal map).
And there are causal limits at play here... How much data can your computer handle in memory? If you are chunking up your data into seporate files, how do you keep annother file(s) as index for fast search and pointing into the data itself? There are ideal ballances to shoot for in terms of data file size and index file size. I have used schemes that maintain this ideal by cleaving and or combining data files when they reach arbitrary size thresholds (pointer index files updated in step). All of this points to why it makes sense at times to interface your stack to a professional data base and let it do all of this structural efficiency heavylifting (that is what it is there for). I like to build my own cause i like to learn... But the obsession is almost killing me. -----Original Message----- From: "Thierry" <[EMAIL PROTECTED]> To: "RevList" <[email protected]> Sent: 1/16/2008 8:25 AM Subject: importing a bunch of files Hi, Another thread about kind of Database :-) For a specific project, I need to implement this: I have an arbitrary set of text files stored on the disk in an arbitrary numbers of directories, within a root one, ie: dirRoot/ dirRoot/f1 dirRoor/f2 dirRoot/dir2/f3 dirRoot/dir2/dir3/f4 dirRoot/dir4/f5 ....... When it comes to deliver the project, I want to import all theses files, and the tree organization inside a stack ( datas only stack ). I'm thinking of mapping each directory to a group; the first group would be named dirRoot, dir2 and dir4 would become groups named dir2 and dir4, children of the first group, dir3 a group inside dir2 group, etc... and for the files, importing them in custom properties of these groups with the same name as the original files. Let say it could be a hundred files or even more.... One extreme could be one group with a hundred properties, another one a hundred nested groups with one property for each group. Do you think this is realistic to do so, and what kind of pitfalls i can find on the way ? Another solution could be to create as many text fields as files, with each field named with the full path of the corresponding file..... ? Any hints or thoughts are welcome, before I jump into it. Regards, Thierry _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
