[cad-linux] Re: database access methods
- From: Jim Parker <hopeye@xxxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Fri, 16 May 2003 11:03:15 -0400
G'Day !
GtkCAD does it this way. There is a standard Library API that covers
all normal geometric entities. So if a function needs the location of
a vertex, it uses this API.
But lets say a module needs to know the Over all length of a ship
hull. Generic GtkCAD does not know what a ship is let along it's
length (after all civil engineers have no need for this table.) So
GtkCAD allows the module to add a table to the database and manipulate
the info in the new table, but it uses the standard library for generic
model information.
I have a question for the list. Is it better to have :
1) one huge database for all models, from every project.
2) a different database for each project.
3) a different database for each model.
The other question I have:
GtkCAD is capable of multile drawing areas. I determine the
orientation of the drawing area by a normal vector that points at the
viewer. Does anyone know a simple routine to convert a vector to
OpenGL rotation angles ? You can not use simple force resolution
routines.
TIA
cheers,
Jim Parker
On 2003.05.16 10:25 Brian Johnson wrote:
>
> I thought part of the concept was to make the storage system easily
> expandable
>
> I thought that the ability for an app to make it's own tables within
> the project db
> provided that.
>
> I didn't think that the standard had to include a precise description
> every bit of
> data that anyone could ever possibly think of putting in the db
>
> I also didn't think that for someone to add info that was not already
> specifically
> included in the standard complete with access library functions call
> to read/write
> to it would require the approval of the standard committee and and
> formal inclusion
> in the standard.
>
> I do think that this approach will kill this initiative since it would
> require
> anyone who wished to use it for data storage for any objects other
> than for what it
> is already designed to get "permission" (aka inclusion in the
> "standard") to be
> allowed to do so.
>
> I can understand such a strict standard for parametric object data but
> if there is a
> project db, there is other info that would be useful in there that
> perhaps doesn't
> need such tight controls
>
> If there is a db per project, the ability to add additional tables for
> custom data
> is a really good feature. Whether that additional data format is
> published or not
> (for other apps to use) should be irrelevant if it is stored in a
> separate table
>
> IMO, the "standard" should apply to the base tables required to get a
> working cad ui
> and should allow (how would you prevent this anyway?) and anticipate
> the addition of
> other tables
>
> I also still don't realize that native storage in a parametric format
> is "better"
> than storage of smaller building blocks and have a seperate table of
> the parametric
> objects that the "kernel" could use to mainpulate the smaller building
> blocks but
> perhaps that is simply because I can't fathom how it would work in my
> business where
> we do road design, sewer design, site design, building design,
> structural design,
> machine design, electrical design. How can a parametric model be
> designed to handle
> all objects including drafting devices like text, tables, borders,
> leaders, etc
>
>
>
>
>
> Eric Wilhelm (ewilhelm@xxxxxxxxxxxxx) wrote:
> >
> >
> >> The following was supposedly scribed by
> >> Brian Johnson
> >> on Thursday 15 May 2003 09:00 pm:
> >
> >>Maybe it's that I'm not a programmer, but I can't understand why an
> access
> >> library is required for any and all access to the db
> >>
> >>If I were writing an app that would do some simple queries to the
> db, and
> >> the data I wanted was in an easy to access format in the db, I
> would not
> >> use an access library if a direct SQL connection were possible.
> >
> >Sure, if you know where to look and what the information means, but
> when you
> >need to poll the database for the results of parametric
> relationships,
> >wouldn't it be easier to access with something like:
> > *attachment_point = get_location(door, *levels, type);
> > length = trace_wire(circuit, *extents);
> >and etc. than to read each of the relationships (conduit connects to
> bracket,
> >bracket connects to beam, beam connects to column, etc, etc) and
> construct
> >the length of wire or determine how the door is hung in the frame?
> >
> >>Same with writes to the db if my app were creating it's own tables
> within
> >> the project db for data not available elsewhere in the db.
> >
> >Why would your app be creating its _own_ tables in the project db?
> >This is contrary to the purpose of the system, which is
> interoperability.
> >Does your app do something that no other app in the world can do or
> produce
> >data that wouldn't be useful to any other app in the world?
> >
> >> ie I wouldn't
> >> write an app specific access library to reproduce what is already
> available
> >> via SQL
> >
> >I'm not talking about reproducing the functions of SQL, I'm talking
> about
> >implementing a standard method of storing and sharing data in a
> well-defined
> >and structured way which would be readily available for use by any
> developer.
> >If you are going to include some SQL code in your program to access
> the data,
> >why not just use a set of functions from a library meant to access
> that data?
> >
> >Furthermore, if you are going to _write_ to the database, every other
> program
> >utilizing the system will greatly appreciate it if you do it
> according to the
> >standard. If that standard is defined by the access library, you
> don't have
> >to worry about implementing the standard correctly, just use the
> library.
> >
> >More importantly, the other apps don't have to worry about you
> implementing
> >the standard correctly iff you use the functions in the library.
> >
> >--Eric
> >
>
> --
> Brian Johnson
>
> This is where my witty signature line would be if I bothered to edit
> this line :)
>
>
>
>
Other related posts:
