Re: Polygon data modelling question

Qingqing,

Thanks a lot for the advice. It's sorta what I had thought all along, but it's good to hear a more knowledgable person agree and give me more to think about.

Thanks,
John

"Qingqing" <zhouqingqing_at_excite.com> wrote in message news:cee59be7.0201170717.2e8bdae0_at_posting.google.com...
> Hi John, in your question, there are two alternatives. One is encoding
> each coord as a single column, the other is store them together as a
> text column. We have to consider the problem from the efficiency and
> extensibility.
>
> From extensibility standing, the first method is better. Just think
> why DBMS first have to parse the SQL into a syntax tree, etc. This is
> because the decomposed things are more easily to handled in most
> cases. However, if you think no more functions of the project will be
> demanded, the second is also good.
>
> From efficiency aspect, I can't easily give a conclusion. Because in
> the first method, there are many rows storing one spacical object, so
> if you use "update ... where id = obj_id" then: if row-level-lock is
> supported in dbms, this may be not a problem, if only page-level-lock
> is supported, this will cause performance degrade in frequent-update
> applications. For the second method, there is no problem like this
> since one row one object.
>
> Method 1 and 2 don't have big gaps - they can be changed into each
> other. So don't worry too much about the design and initial
> implementation, both way are right in your case though I prefer the
> first one. Re-engineering can't be avoid since we can't predict the
> future.
>
> (1) dbms are so different - know their performance by testing your
> plan on it;
> (2) re-engineering can't be avoid;
> (3) use simple way if you can't predict the future;
>
>
> regards,
>
> Qingqing
>
>
>
> "John Palmer" <jopalmer_at_mail.vt.edu> wrote in message
news:<a24amu$qd$1_at_solaris.cc.vt.edu>...
> > Hi all,
> >
> > I have a question concerning a data model quandry I've gotten myself
into.
> > I need to store the absolute coordinates of pieces of wood as they exist
in
> > a truss, so that I can draw an entire truss. My original idea was to
store
> > pc_id, coord_id, xcoord, ycooord, zcoord for each coordinate for each
piece
> > in a table called pcs_coord. However, there is also the option of
simply
> > storing a comma delimited text-string in a single field and then pulling
out
> > that field's data and parsing it each time for to draw it. So my
question
> > is: what is the best way to do this? We won't be doing too much editing
of
> > the coordinates, if any, for now. We will be using these coordinates to
> > generate pictures only for now. The only reason I like each coord as a
row
> > is that it makes it easier for me, in the future, to pull back these
> > coordinates in an XML format like Scalable Vector Graphics without
having to
> > do parsing. Also, I can more easily find the max coordinates to do some
> > scaling. But a co-worker says that if you never want to only return one
> > row, ie one point, then it shouldn't be a row and that storing
coordinates
> > individually is a common mistake people make and we should learn from
them.
> > Does anyone have any ideas on what I should do?
> >
> > Thanks in advance,
> > John Palmer
Received on Thu Jan 17 2002 - 17:33:01 CET