To be more clear:
> client:
> id: {type: integer}
>
> users:
> user_id: {type: integer, primaryKey:true, foreignTable: client,
> foreignReference: id}
> id: {type: integer}
>
> profiles:
> client_id: {type: integer, primaryKey:true, foreignTable: client,
> foreignReference: id}
> id: {ty
Sid 'Neko Tamashii' wrote:
Is this model (Symfony's YML based) wrong based on normalization?
propel:
client:
client_id: {type: integer}
foo:
client_id: {type: integer, foreignTable: client, foreignReference:
client_id}
foo_id: {type: integer}
bar:
client_id: {type: inte
Is this model (Symfony's YML based) wrong based on normalization?
propel:
> client:
> client_id: {type: integer}
>
> foo:
> client_id: {type: integer, foreignTable: client, foreignReference:
> client_id}
> foo_id: {type: integer}
>
> bar:
> client_id: {type: integer, foreign
Thanks guys,
Sebastian
On 8/28/07, Bart Degryse <[EMAIL PROTECTED]> wrote:
>
> Im using Django as my Object relational Mapper so im pretty sure I
> can not add a constraint such as ...
> Then you should seriously consider changing your mapper.
>
> >>> "Sebastian Ritter" <[EMAIL PROTECTED]> 2007-
Im using Django as my Object relational Mapper so im pretty sure I can
not add a constraint such as ...
Then you should seriously consider changing your mapper.
>>> "Sebastian Ritter" <[EMAIL PROTECTED]> 2007-08-28 16:37 >>>
Thanks for the information.
Both tables would be exactly sames apart fr
On Tue, Aug 28, 2007 at 04:15:01PM +0100, Sebastian Ritter wrote:
> > I'd put it in its own table, probably, unless you're going to use it
> > frequently.
>
> Why would frequency of use change whether or not I use one or two tables?
If you have a possibly-large field that does not get used very
Hi,
On 8/28/07, Andrew Sullivan <[EMAIL PROTECTED]> wrote:
>
> On Tue, Aug 28, 2007 at 03:37:22PM +0100, Sebastian Ritter wrote:
> > Thanks for the information.
> >
> > Both tables would be exactly sames apart from the foreign key relation
> to
> > clients or services.
>
> Hmm. Are the services
Hi,
The views option sounds best in my opinion but sadly i cant play with things
like inheritance or views as Im using Django as my ORM and since its
relatively new, it doesnt yet support such database operations.
Id like the ids for each "entity" to be serial and hence there would be
overlap bet
On Tue, Aug 28, 2007 at 03:37:22PM +0100, Sebastian Ritter wrote:
> Thanks for the information.
>
> Both tables would be exactly sames apart from the foreign key relation to
> clients or services.
Hmm. Are the services or clients tables different? A useful rule of
thumb is that, to the extent
On Aug 28, 2007, at 6:47 AM, Sebastian Ritter wrote:
Hello,
I have a fairly basic question about database design where im not
sure which approach is considered correct.
I have two different entities: Clients and Services. Both allow
users to add progressive updates about the two entities.
Thanks for the information.
Both tables would be exactly sames apart from the foreign key relation to
clients or services. I agree that it seems strange to have one column that
is always null. Im using Django as my Object relational Mapper so im pretty
sure I can not add a constraint such as : CH
On Tue, Aug 28, 2007 at 12:47:45PM +0100, Sebastian Ritter wrote:
> > The update/message format is exactly the same for both. Should I make two
> > different tables:
> > one table with extra columns : is_client, client_id, service_id, where
> > either client_id or service_id would be null depend
Hi
I would create one table to log updates with type field and one id filed
that contains either client id or service id according to type. On such a
table i would forget about foreign keys (thay are better to be avoided
anyway if you have millions of records in tables).
That way you can share cod
Hello,
>
> I have a fairly basic question about database design where im not sure
> which approach is considered correct.
>
> I have two different entities: Clients and Services. Both allow users to
> add progressive updates about the two entities.
>
> The update/message format is exactly the same
14 matches
Mail list logo
