Hi Brett, a topic near and dear to me ;)
For me, I find the model I choose is impacted by:
- data structure
- volume
- time [development]
- performance requirements
- whether the data is static / dynamic
For key / value pairs I might use:
states: ["VIC" "Victoria" "NSW" "New South Wales"]
select states "NSW"
or
states: [VIC "Victoria" NSW "New South Wales"]
states/NSW
The first form being usefull in conjunction with parse, eg.
ini: parse read %settings.ini "="
For large key / value sets I might use hash! instead of block!
If the data takes the form of key/values I tend to use composed objects
such as:
attributes: context do has [spec][
spec: make block! 1024
foreach [attribute t w] load %Database/Attributes.dat [
insert tail spec compose/only/deep [
(to-set-word attribute) context [type: (t) width: (w)
used: 0]
]
]
spec
]
For large amounts of data (100,000+ records), I try to express / represent
the data as tables of columns and rows (I'm an RDBMS guy after all ;) ).
I also try to store as much meta-data in the file-system as I can, for
example, I may have a file like the following:
/c/rSQL/Contacts/Name.s24
which tells me that the "Contacts" table has a "string" column of 24
characters width named "Name".
> Another interesting line of discussion would be on
> useful REBOL idioms when programming a REBOL app to talk SQL.
Understatement! Having spent the last year [on and off] designing a REBOL
RDBMS, I can assure you that there is more to it than will fit in a quick
email reply (I am writing my "thesis" [ie. documentation] on my REBOL
RDBMS design as we speak). ;) An interesting question that this raises: Is
it better to have a SQL parser or a SQL dialect?
Regards,
Ashley
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
