Subject | Re: [Firebird-general] IBM moves the database goalposts - xml related |
---|---|
Author | Lester Caine |
Post date | 2004-12-10T20:37:41Z |
I'm having to jump through the hoops of UK eGov schemas. Some of them
are just so contorted that you don't stand a chance of providing the
data that they require, but you can at least provide a subset. THAT is
an acceptable solution, and it is up to the target system to handle the
holes.
I specifically asked the question of the eGov developers. How are we
supposed to manage data with the mess that is building up in the
schemas, and the answer was. Use whatever you want to store the data,
THAT is not the job of XML, only handling queries BETWEEN dissimilar
systems. So I can ask for the address record for NINumber xx123x and I
will be supplied with a record in some format defined by the address
schema. Movements of bulk data are not planned to use XML - it's too heavy.
So XML just provides a different version of SQL query, and defines how
it wants the results - with several options. Working things that way
should not be too difficult, but we still have the full relational model
of the data within the database, and hopefully the right indexes to
quickly find the information requested. If that is and XML engine I
would not expect it to perform very well against a nice Firebird/Vulcan
core when accessing the same sorts of data.
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
are just so contorted that you don't stand a chance of providing the
data that they require, but you can at least provide a subset. THAT is
an acceptable solution, and it is up to the target system to handle the
holes.
I specifically asked the question of the eGov developers. How are we
supposed to manage data with the mess that is building up in the
schemas, and the answer was. Use whatever you want to store the data,
THAT is not the job of XML, only handling queries BETWEEN dissimilar
systems. So I can ask for the address record for NINumber xx123x and I
will be supplied with a record in some format defined by the address
schema. Movements of bulk data are not planned to use XML - it's too heavy.
So XML just provides a different version of SQL query, and defines how
it wants the results - with several options. Working things that way
should not be too difficult, but we still have the full relational model
of the data within the database, and hopefully the right indexes to
quickly find the information requested. If that is and XML engine I
would not expect it to perform very well against a nice Firebird/Vulcan
core when accessing the same sorts of data.
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services