Re: An interesting database question
Re: An interesting database question
- Subject: Re: An interesting database question
- From: Arturo Pérez <email@hidden>
- Date: Wed, 7 Apr 2004 22:14:56 -0400
To start, let me just say that it's a far out there idea. As is
everyone else, I'm curious as to why whoever proposed it thought it
would beneficial as it is unusual, to say the least.
However, it's an interesting concept to explore. A gedanken experiment
if you will.
On Apr 7, 2004, at 6:16 PM, John Spicer wrote:
We will have a database (accessed with webobjects, of course!) that
will have accounts in it that information is written into.
We will also have N patients (N being an unknown number).
All the databases I've seen would do this as one table (account) with
some way of identifying which row belongs to which patient.
Yep. You can call it "data normalization" or you can call it a "design
pattern." It's a proven technique. However, if you need to firewall
patient data from each other or something else then it may not be the
correct approach. Let's say you need this super-strict separation of
data.
It has been proposed that instead of one accounting table, we have N
tables, one for each patient.
Not sure what that would buy you. It certainly does not offer any
additional security. Why not separate (tiny) databases per patient?
Or separate schemas? Each patient could have his own schema that's not
public and no one else would be able to see it. This gives you very
separate data and improved security over the more traditional approach.
Separate databases might be kewl because you might then be able to fit
them onto a smart card and let the patients carry their data around.
Each table would be created on the fly (from the app) using some kind
of eo modeler commands.
I was the architect of a team that did something like this. We weren't
using WO at the time so we used straight SQL DDL to create views and
tables on the fly. It was very very neat.
I don't know if it's possible yet. I don't know if the database we
deploy would allow creation on the fly (due to licensing
considerations, perhaps).
Well, clearly this could kill the idea right there. You should switch
to PostgreSQL, Firebird or something else that is free and has views,
etc.
The question I guess is in three parts:
[1] Can it be done using EOModeler calls on the fly;
Don't know. We did it with raw SQL DDL (e.g. "CREATE VIEW
<blah><blah><blah>").
[2] Has anyone seen it done, and if so, why?
As mentioned above, I did/designed something similar using straight SQL
DDL. It was to support a user-driven data grouping scheme. Using
patient data it would be something like "create a group containing all
patients with diabetes" If the group was to be a point-in-time group
it had to be a table and if the group was to be automatically updated
it had to be a view. I suppose, in retrospect, we could have just kept
the SQL DDL around but then we'd have to be good at
parsing/understanding SQL instead of just being good at spewing it :-)
[3] Should it be done?
Probably not. There's got to be a justification beyond "Gee whiz how
kewl is that!"
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.