[cad-linux] Re: Database Use Cases
- From: Thomas Schmidt <thomas.schmidt@xxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Mon, 19 May 2003 10:39:47 +0200
I absolutly agree with you that a storage mechanism should be hidden
from a end user. But lets use your example, the end user wants to change
an aircraft frame. To to that, the user has to access the
frame. There must be something in the CAD's menu allowing
to end user to "Open" the data of the frame. Usually this is "File"->"Ope=
n",
or something like that. The user has to find the aircraft frame.
Somehow. Now consider that the backend is a database. This might
allow the user to search for the frame in more sophisticated ways
then browsing a filesystem. And there might be revisions. The user
might have the option to select a revision. Or the user knows that
the frame is part of the "project" xy, so the project can be browsed.
Would this already be considered as "non transparent database integration=
" ?
I think that Database integration about data stoage and retrieval.
> > aircraft frame from the type used at station 425 to the type used at =
550,
> > and the "system" fixes it.
I would implement this not on the database level as it is a (aircraft) sp=
ecific=20
functionality. I would implement this as a separate application module.
But this is again more technical.=20
@phrostie
Would you mind to send me the name of the CAD system used at
your training? I'm asking because I saw a database integration for
only one CAD system and I somehow liked it. But maybe the marketing
was better than the product.
> On Fri, May 16, 2003 at 05:11:20PM -0400, phrostie wrote:
> > if done correctly the end user should never know about the database.
> > all he/she should know is that he needs to change a door on the 5th f=
loor
> > from a single 30" wide to a double door that spans 60". or you chang=
e an
> > aircraft frame from the type used at station 425 to the type used at =
550,
> > and the "system" fixes it.
>
> I think this is (or should be) one of the primary design goals. The
> abstraction of the access library along with the modeling_kernel/UI
> should be more than enough to keep most end users far away from the
> database... The only ones that should need to know about it are other
> app devs.
>
> -Lee
Other related posts:
