[storm] data separation

[Gerdus van Zyl]

Personally I would do it with one table. With a database view or query
with the protected data left out.

FooState sounds suspect, just because it changes frequently does not
mean it needs a seperate table.

You might also check out an object database (eg. ZODB) since designing
a good relational data schema is hard to get right.

>Could you maybe tell me why this is a bad idea?
Because in 90% it means the table structure is wrong. But if you have
your heart set on splitting the one table into three by al means use
the same primary key since it's really one table. I of course could be
understanding you incorrectly, feel free to send a list of fields of
what needs to be stored :-)

~Gerdus

On Wed, Jan 28, 2009 at 10:19 AM, Johan Rydberg
<johan.rydberg at edgeware.tv> wrote:
> Gerdus van Zyl skrev:
>>>
>>> But is it a good pattern to separate data in this way?
>>
>> That depends on the data of course, could you give a little more
>> information?
>
> The main reason is that I want to protect some data; for example
> personal information.  The "unprotected" data will be serialized
> and sent to external sinks.
>
> Another reason is that some data is static, in my previous example,
> only FooState will be frequently updated.
>
>> And why do you want to share a primary key across multiple tables?
>
> Because it's really a tuple; (Foo, FooState, FooPrivate).  Plus
> you eliminate an integer in the table.
>
> FooState and FooPrivate will always be created alongside Foo, so
> in practice they will always have the same id anyhow.
>
>> It's almost never a good idea.
>
> Could you maybe tell me why this is a bad idea?
>