On Fri, Nov 21, 2008 at 7:12 PM,
<a@9srv.net> wrote:
On db ¡ê fs conversions:
// datas (and their relations) MUST be kept consistents.
there's two things you could mean here: either the
relations between the data fields/types or the relations
between their values.
Both are really important.
When a product change its code (aka pk) for business' reasons, I need have it changed automatically in any place its referred in the database.
Or if a dumb employee try to delete a product category (supposing he's allowed) I have to be sure that the remaining data don't loose meaning.
SQL databases are interesting because they don't do anything to keep the relations
consistent, at a schema level.
They do, if you instruct them about the relations amont your tables.
(MS Access don't count as a db :-D)
there are some cases where
this is valuable, but most of the time it just puts more of
the burden on the application.
Application should HANDLE data.
But datas are a rapresentation of a reality which have a meaning!
A relational database don't have to know how datas are collected or used.
But it has to keep meaningfull the rappresentation.
enforcing consistency between values is a whole different
matter.
Obviously I'll check user provided data types before sending them to the db.
BTW, db also have to, for different reasons.
I've to protect my database from malicious sql injections, it has to protect datas from inconsistency (say a string in a date field).
and largely needs to be done in the ap anyway (say
your DB rejects a submission; are you just giong to panic,
say "try again", or try and figure out what it didn't like?).
Well, accoding to the needs, different strategies are followed.
Sometime the error will go (human translated :-D) to the user, others a signalation will go to the developers.
Here is a disadvantage: user provided data are double checked (some time checks are 3, when also a remote client do the check, say via javascript).
I reflected a lot about this, but (still) found no solution.
I just notice that the reasons for the checks are different:
1. DB check to keep data consistents
2. Application check to validate data against malicious ones
3. (eventually) browsers check to help the user and to save a little of band
If you need data consistency (anyone need I think) DB have to check.
If you can't trust the user application have to check.
If you don't have enouth Gbits you could also need to repeat the data check in the browser.
// And MUST be updated frequently, in transaction.
just curious: what is it about "transactionality" that you care
about? atomicity, logging, roll-back (atomic roll-back)?
Atomicity and rollback. (logging is useful too...)
I need to be able to atomically save related tuples in different tables, since (for example) those different tables could be simply modelling ONE real entity (say an order or a family).
// Application code cannot do that, since it's too subject to
// modifications...
i'm not convinced. you can simply... not modify it!
You are right... I like my applications... (almost all...)
I really don't want... but they paid me! :-D
unless you've got a database you're exposing to multiple parties
and you're worried one is going to mess things up for
others, but in that case i think exposing the database
directly is pretty risky regardless.
There why we use REST... but that's another history...
the application i've worked on with the most complex data
constraints had an "ontology layer" that everything that
wanted to do data access went through.
'till now our "ontology layer" was the database itself.
But I would be curious about how this ontology layer was implemented. Really!
// Moreover such a dbfs should allow rapid development of
// views over data (with different permissions) by simply
// write the query in a file and then open the file for reading
// the XML.
somewhere around here i've got a /chan/pq for inferno that
makes connections to a pq database. each open is a new
logical connection; you write the query and read the result.
results were not in XML, and pq has no updates (at current).
where? I could start from there... (even I'm sure that it has to be coded in C)
i think you've got some very interesting ideas on sessionfs
in particular. i have more thinking to do there.
You're welcome!
I realized that the sessionfs has to cooperate with the rewrite engine...
oh, probably an aside: from an application design point of
view, DO NOT empty my shopping cart just because my
session timed out. i should be able to pick up where i left
off. i'm not sure how hypothetical that example was, but
that's a common source of irritation for online shopping.
It was hypothetical. But, to keep back your cart you MUST be logged (some times adding to the shopping cart don't require authentication) and the cart status have to be saved somewhere (the database?).