Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: How can I store a mathrix in a table

Re: How can I store a mathrix in a table

From: <prochak_at_my-dejanews.com>
Date: Thu, 10 Sep 1998 16:16:45 GMT
Message-ID: <6t8u1d$777$1@nnrp1.dejanews.com>


In article <35f6fbf2.5006303_at_news.mad.ibernet.es>,   jgonzalezs_at_nexo.es (Julio G. Suarez) wrote:
> Hi all. I'm working with Oracle 7.3 and this is my trouble for the
> week:
> Supose that we want to store the history of faults on pieces, so we
> need a table with the piece code and the fault number as primary key.
> The damage is described by a 10 x 10 square pattern, like this:
>
> 0 1 2 3 ... 10
> 1
> 2 x x
> 3 x
> ....
> 10
>
> In this example, the damage (shown whith an "x") is on the points
> (2,2), (2,3) and (3,2).
>
> In order to store this kind of data, I have think on three ways:
> 1.- Add 100 boolean-like columns to the fault's table.
> 2.- Add 10 number columns whith the translated to decimal ten bit
> binary number.
> 3.- Create a child table whith as rows as damaged points for a fault.

Do you mean a table like:
table faults (
pieceID number

xloc     number
yloc     number

)
which lists each 'X' (ie sparse matrix storage)

or like
table faultpattern(
patternID number
x1y char(10)
x2y char(10)
...
x10y char(10)
)
which holds the whole pattern in one record

>
> Could you suggest me the best way?
>
> Thanks!
>

Best in what sense? Are you going to
 store lots of these and query them infrequently?  store few of them and query them often?  store few of them and query them only for display?  store lots of them and do pattern searches? (most likely)  store lots and do statistical analysis?  store lots of them and you have limited tablespace? Will the queries
 use other keys to find the pattern column?  use the pattern column to find the other information in the table?  use combinations of columns, including the pattern column?

Your requirements (how you use it) will determine the "best" way.

If you are going to do pattern matching or statistical analysis, I think the binary encoding as integers may be your best choice. You have essentially a 100digit binary number. With 32bit integers, you need atleast 4. Maybe the mapping/computation can be easier if you use 5 (2rows each, encoding 20bits). A straight binary mapping is efficient, but it might be difficult to compare similar but unequal patterns.

The child table is a possibility that might solve this. And if you are short on space this might help too. If the number of patterns to be stored is expected to be less than 4billion, then you could use a single integer as a key into a child table that holds the actual patterns. The cost of pattern matches goes up if you need to compare similar patterns, but direct matches goes down (you only need to compare one integer). If you have a good "hash" algorithm, then you can compute the integer key and maybe be able to come up with key values that are close to each other when the patterns are close to each other (by whatever criteria you use for judging "closeness").

If you don't have a good hash algorithm, then you need something to handle comparing patterns in the child table. The child table might have columns that link to other patterms that are judged by you to be similar. Setting up the child table might be difficult, but once done, it could speed your comparisions considerably.

Sorry I didn't answer more specifically. Your question left me with just too many options. (defining "best" is always difficult!)

Give us some more information and maybe we can help in more detail.

--
Ed Prochak
Magic Interface, Ltd.
440-498-3702

-----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum Received on Thu Sep 10 1998 - 11:16:45 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US