On Tue, 1 Apr 2008, Andrej Ricnik-Bay wrote:
On 29/03/2008, Ben <[EMAIL PROTECTED]> wrote:
I'm working on a project which requires me to keep track of objects,
each of which can have an arbitrary number of attributes. Although
there will be many attributes that an object can have, the data ty
On 29/03/2008, Ben <[EMAIL PROTECTED]> wrote:
> I'm working on a project which requires me to keep track of objects,
> each of which can have an arbitrary number of attributes. Although
> there will be many attributes that an object can have, the data types
> of those attributes won't be all tha
Ben wrote:
I'm working on a project which requires me to keep track of objects,
each of which can have an arbitrary number of attributes. Although there
will be many attributes that an object can have,...
Anyway, this seems like a common problem without a perfect solution, and
I'm sure people m
Ben wrote:
> create table attrs (id serial primary key, name text);
> create table obj (id serial primary key, name text);
> create table att (oid int references obj.id, aid int references attrs.id,
> value_int int, value_float float, value_text text, value_bool bool,
> value_date date);
I th
I'm working on a project which requires me to keep track of objects,
each of which can have an arbitrary number of attributes. Although
there will be many attributes that an object can have, the data types
of those attributes won't be all that varried (int, float, text,
boolean, date, etc.)
On Sat, 24 Feb 2007 00:59:02 -0800
[EMAIL PROTECTED] (snacktime) wrote:
> Say you have 8 different data models that are related enough to share
> roughly 70% of the same fields, but the shared fields are not always
> the same. And also within any given model, some fields can be empty.
> The busin
Say you have 8 different data models that are related enough to share
roughly 70% of the same fields, but the shared fields are not always
the same. And also within any given model, some fields can be empty.
The business logic is that data is pulled from all the data models and
put into a common
On Wed, 2005-08-17 at 13:40 -0700, Bill Moseley wrote:
> a course
> and class share so many columns. ...and
> I worry about changing a column type on one table and forgetting to
> change it on the other table.
Postgres types might help here. You could probably create a type that
contains the com
On Wed, Aug 17, 2005 at 07:41:20PM +, Matt Miller wrote:
Thanks for responding, Matt:
> create table course (id serial primary key,
> description varchar);
> create table teacher (id serial primary key,
> name varchar);
> create table course_teacher
Bill Moseley schrieb:
>On Wed, Aug 17, 2005 at 10:05:39PM +0200, Sebastian Hennebrueder wrote:
>
>
>>> Con: Column duplication in the two tables -- two tables look a lot alike
>>> Need to have duplicate link tables (one pointing to each table)
>>>
>>>
>>>
>>>
>>They are not duplicate
On Wed, 2005-08-17 at 10:49 -0700, Bill Moseley wrote:
> The parent object is a general course description, and the
> child object is a specific instance of a course
> ...
> tables that represent classes taught at a
> school. The parent object is a general course ... the
> child object is ... a "c
I originally was planning on asking about Postgresql inheritance, but
after reading the docs again I do not think that it applies to my
design.
So, now I'm asking a rather basic schema design question.
I have two related objects where one inherits column values from
another. No, that's incorrect
12 matches
Mail list logo
