Skip site navigation (1) Skip section navigation (2)

Re: Question about fk and uk for Database Modeler

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Luis Ochoa <ziul1979(at)gmail(dot)com>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Question about fk and uk for Database Modeler
Date: 2011-05-23 19:53:32
Message-ID: 4DDABB3C.3060202@lelarge.info (view raw or flat)
Thread:
Lists: pgadmin-hackers
On 05/22/2011 11:02 PM, Luis Ochoa wrote:
> On Sun, May 22, 2011 at 2:10 AM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)info>wrote:
> 
>> On 05/20/2011 05:26 PM, Luis Ochoa wrote:
>>> I'm checking right now database designer way of updating / creating
>> foreign
>>> keys from pk, and as part of this work I want to add uk / fk
>> implementation,
>>> but I want to check some points before, because I'm not totally sure
>> about
>>> it, please I'll appreciate your help.
>>>
>>> 1.How should I add option to choose between pk and uk as source of
>> foreign
>>> key ?
>>> my idea: right click over relationship let me choose source of fk:  uk
>>> (allow me to choose which uk of many) or pk
>>>
>>
>> Fine to me.
>>
> 
> Implemented yet.
> 
> 
>>
>>> 2. When I create a fk some columns are added to table
>>
>> Why? a user could create a FK with existing columns.
>>
> 
> Right, thanks for point me that, because I focused on programming and not at
> usability :(  but right now is implemented in this way:
> 
> - User created a relationship between tables, by default of pk kind, but
> dependents of kind a fk column is added to destination table for each pk/uk
> column from source table with name tablesourcename_column.
> 
> Next user is (or will be) able to:
> - After fk columns are added he can change name for whatever he likes.
> (implemented soon)
> - Only If user select to use auto generate names, a change at table source
> column name automagically change destination fk name to adjust it. User will
> be able to select for each column what he likes auto generated name or
> customized (sync is implemented yet, but selection of user for customized or
> auto generated name will be implemented soon).
> 
> - Now after your question, I notice that a user is able to use an existing
> column as fk, and then I will create a fk->column mapping dialog for this
> goal, that allow user to choose which existing column is binded to which fk.
> (implemented soon)
> 
> Suggestions?
> 

Nope. This new dialog is not important right now. Keep in mind; basic
functionalities for the first patch. Only TODOs.

>>> and MATCH matchtype right
>>> now is only MATCH FULL but I have more options to choose like: MATCH
>>> PARTIAL(is still no implemented yet or docs are outdated )  MATCH
>>> SIMPLE, . Question here is should I let the user to choose between match
>>> full and simple (not partial yet)?
>>
>> Right click on the relationship, and the MATCH FULL/SIMPLE choice is
>> available in this contextual menu.
>>
> 
> Ok. I'll add this menu item.
> 

OK.

>>> reference:
>>>
>> http://www.network-theory.co.uk/docs/postgresql/vol1/CREATETABLE.html#SEC284
>>>
>>> 3. suppose that I created a fk from a pk if I add hierarchy all fk
>> columns
>>> become fk/pk that's fine, but if I created a fk from an uk and I add
>>> hierarchy, what should be the normal behavior?.
>>
>> I don't understand what you mean here.
>>
> 
> Ummm my mistake bad question, probably I was sleepy.
> 
> This is:  Should I allow to mark as Identifying relationship a foreign key
> from an Uk?
> 

Yes.

> 
>> Which TODO are you working on?
>>
>>
> I'm working right now with files instead TODO, because I check every file
> for every TODO and then implemented, fixed it (with related files) , some
> TODOs (minimal as possible) are delayed until now this are Delayed for
> later:
> 
> 1. dditems->figures->ddTableFigure.cpp  //DD-TODO: fix all model to allow
> all options from
> http://www.postgresql.org/docs/8.1/static/sql-createtable.html
> 

OK.

> 2. dditems->figures->ddTextColumnFigure.cpp //DD-TODO: Add composite column
> functionality by addin subcolumn for composite types, but be careful:
> composite types can be recursive (using inside other composite types)
> 

OK.

> Status Righ now:
> - dditems->figures (probably most important TODOs for modeler were here)
> TODO are almost done with some related classes and some parts of draw
> 

OK, great.

Thanks.


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

In response to

pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2011-05-23 19:54:18
Subject: Re: A question about database designer first deliverable
Previous:From: Luis OchoaDate: 2011-05-22 21:06:48
Subject: Re: A question about database designer first deliverable

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group