Hi Romano, >The advantage of row/col is for export functions. It can be easy converted in >a CVS db for more complex works or to change direction if you see that db >becomes too big. But i'm open to every solutions. In my custom db i use nested >blocks which are not easy converted in a row/column struct.
There are many advantages to a row/col based design. I don't mean to preclude it but I want to also do nested blocks or complex objects or even simple name:value pairs. >> Small and flexible are more important to me than fast. > >I think it could be modular: basic functions in the main script, additional >functions, also the same but more complex, in a second one compatible. About >velocity, i had problems until i started using hash! for indexes. Modular is good and having different functions that match the task in complexity also sounds good. This is why I want to start at the bottom - the interaction with a binary file. Then, on top of that we could build functions to manage rows and columns, or objects, or name:value pairs and so on. >> I don't mind some complexity as long as the design is built to manage >> most of it internally. > >I think about dimensions. But it is a fixation of mine. You would be right at home with the Pick/UniVerse database system then. It is multi-dimensional in nature. I am however just an relational db guy who wants more options than the traditional ones provide. I also want it all to be simpler as well. (Can you say dreamer? :-)) Thanks, Rod. Rod Gaither Oak Ridge, NC - USA [EMAIL PROTECTED] -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
