[cad-linux] Re: database access methods

  • From: "Brian Johnson" <bjohnson@xxxxxxxxxxxx>
  • To: cad-linux@xxxxxxxxxxxxx
  • Date: Fri, 16 May 2003 14:25:17 +0000

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: