[Mapbender-dev] PKs for all tables?

[Samson, Marko]

> -----Ursprüngliche Nachricht-----
> Von: mapbender_dev-bounces at lists.osgeo.org 
> [mailto:mapbender_dev-bounces at lists.osgeo.org] Im Auftrag von 
> Uli Rothstein (WhereGroup)
> Gesendet: Dienstag, 30. Januar 2007 10:11
> An: Mapbender Developer List
> Betreff: Re: [Mapbender-dev] Test of RC1 / some thoughts
> 
> dear list-members,
> 
> Marc Jansen schrieb:
> > Hey Marko, hey List,
> >>  
> >> 2. Test of upgrading a 2.4 version
> >>     - everything seems to work fine, too. (The first time 
> I did the 
> >> upgrade, I had all entries of gui_layers twice. Don't know, what I 
> >> did wrong. Whatever, the second time everything worked 
> pretty nice. )
> >>  
> >> Idea:
> >>  I saw, that you set "default_with_oids = true" in the new pgsql 
> >> schema, but wouldn't there be a chance for grouped 
> primary-keys for 
> >> all the pk-less tables, for example the table gui_layer with a 
> >> grouped-pk of fkey_gui_id and fkey_layer_id to prevent 
> double entries.
> >> (same idea for all other tables without PK like
> >> gui_layer,gui_wfs,gui_wms,...)
> > 
> > I second that, if there are no other relevant issues. I can not see 
> > any
> > -- do you? A grouped PK should be the right way to handle 
> theses tables.
> > 
> >>  Or is there a reason, why there are no PKs at some tables? In my 
> >> opinion, there is no logic of having two entries, for example with 
> >> the same fkey_gui_id and fkey_layer_id in table gui_layer.
> >>
> > Yipp, speaking from a database view of things, one does not 
> need two 
> > entries with the same values in the field you named. Am I missing 
> > something?
> 
> I don't now. There may be some technical reasons to publish a 
> layer twice, because nonexisting transparency of services for 
> example. So you have more flexibility for the arrangement of 
> layers. (But I've never seen such constructions in reality...)

But this now can be managed very easy with the new treefolder to move the different layers up or down to handle that problem(additional to the wms_preferences modul). Or have I misunderstood what you meant?

But there are several tables without pks. I think, for a stable datastructure it is advantageous to have pks at every table.