Subject | Re: [IBDI] What else to do? a suggestion - was: What To Do? |
---|---|
Author | Frank Ingermann |
Post date | 2001-05-16T22:43:34Z |
Hi all,
after reading the replies, and some more thoughts, i have a bit of a problem
to decide what access method to use... examples in any version would be quite
helpful (i'd rather go for IBO, but i'd also like something that people who
only know TTables with Pdx could understand & try directly..)
so i decided to make a two-step approach: atm i'm trying to set up a "naked"
database, with just the tables and fields, so i can make an insert script that
pumps a part of my CD collection into that. This gdb has no indexes, triggers,
foreign keys, storedprocs whatsoever. Only domains and tables.
i much like the idea to have several apps done with different tools to access
the same data - a good base for comparisons; but to have a neutral comparison,
the different versions would have to use the same data. so why not have a "bare
to the bone" test database that contains data, but no logic.
2nd step: everyone interested can take it and build their own logic into it,
and their own apps around it with their own tools&languages, as long as the
metadata stays "insert script compatible". This way we could have a test
database, and a variety of solutions for the same problems (if there are
some volunteers to write the apps on different platforms ;) as demo apps on
how-to-use Firebird.
just some more thoughts... could this be a way to go, or are there any
no-no's i missed?
regards & keep on hackin',
fingerman
after reading the replies, and some more thoughts, i have a bit of a problem
to decide what access method to use... examples in any version would be quite
helpful (i'd rather go for IBO, but i'd also like something that people who
only know TTables with Pdx could understand & try directly..)
so i decided to make a two-step approach: atm i'm trying to set up a "naked"
database, with just the tables and fields, so i can make an insert script that
pumps a part of my CD collection into that. This gdb has no indexes, triggers,
foreign keys, storedprocs whatsoever. Only domains and tables.
i much like the idea to have several apps done with different tools to access
the same data - a good base for comparisons; but to have a neutral comparison,
the different versions would have to use the same data. so why not have a "bare
to the bone" test database that contains data, but no logic.
2nd step: everyone interested can take it and build their own logic into it,
and their own apps around it with their own tools&languages, as long as the
metadata stays "insert script compatible". This way we could have a test
database, and a variety of solutions for the same problems (if there are
some volunteers to write the apps on different platforms ;) as demo apps on
how-to-use Firebird.
just some more thoughts... could this be a way to go, or are there any
no-no's i missed?
regards & keep on hackin',
fingerman