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 <[email protected]> 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? > -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
