[cad-linux] Re: database access methods

IMO (that's the only one I've got) the db layout in general should be:

1. one db of multiple tables for general system info including global parametric
models, listing of projects, tables for custom apps (table name to start with 
app
name), etc (anything that would be uniform across projects on that server ..
additional tables as required)

AND

2. one db of multiple tables per project including project specific parametric
models, project management task info, lists of correspondence, billing, tables 
for
custom apps (table name to start with app name), etc (anything that would be
specific to that project)

This layout allows global settings/config/data as well as project specific data.
With certain databases it even allows the project db to be placed inside a 
separate
project directory anywhere on the server (MySQL is like this since you can use 
soft
links in linux to refer to directories in other locations)


It may be found that for drawing data (in the project db), one table for base
building blocks and one table per parametric models with one table to index the
parametric models would be suitable (the base building block table could 
include a
field to link to the parametric model that created it or modified it last .. 
some of
these things may have to be worked out during initial programming)

The global db could also contain the one table per parametric model with one 
table
to index the parametric models


Could we get a wiki setup to work on the documentation of this as a group (like
http://sourceforge.net/projects/sfwiki/)?




Jim Parker (hopeye@xxxxxxxxxx) wrote:
>
>
>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 :)
>>
>>
>>
>>
>

--
Brian Johnson

This is where my witty signature line would be if I bothered to edit this line 
:)

Other related posts: