[cad-linux] Re: database access methods
- From: Roland Krause <rokrau@xxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Fri, 16 May 2003 09:06:38 -0700 (PDT)
--- Jim Parker <hopeye@xxxxxxxxxx> wrote:
>
>
> 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.
>
Interesting! I've been thinking of that but dont have enough knowledge
about databases and especially no experience with them.
>
> viewer. Does anyone know a simple routine to convert a vector to
> OpenGL rotation angles ? You can not use simple force resolution
> routines.
Do you mean a virtual trackball that allows you to rotate the scene or
a camera? I have both, let me know what you need. They are from the
net, if you google for virtual trackball you will find them.
Roland
>
> 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 :)
> >
> >
> >
> >
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
- Follow-Ups:
- [cad-linux] Re: database access methods
- From: Jim Parker
- References:
- [cad-linux] Re: database access methods
- From: Jim Parker
Other related posts:
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- » [cad-linux] Re: database access methods
- [cad-linux] Re: database access methods
- From: Jim Parker
- [cad-linux] Re: database access methods
- From: Jim Parker