AW: [Mapbender-dev] PKs for all tables?

[Samson, Marko]

ALTER TABLE ONLY wfs_featuretype_namespace ADD CONSTRAINT pk_featuretype_namespace PRIMARY KEY  (fkey_wfs_id,fkey_featuretype_id,namespace);

ALTER TABLE ONLY mb_monitor ADD CONSTRAINT pk_mb_monitor PRIMARY KEY  (upload_id, fkey_wms_id);

ALTER TABLE ONLY mb_log ADD CONSTRAINT pk_mb_log PRIMARY KEY  (id);


++++++++++++++++++++++++++++++++++++++
layer epsg had to be to cleaned.  rc1 table backup after cleaning at zip-file.....
I had to delete one WMS, but I forgot the name. Something like eusoil or something like that (layer_id was 13667?)
+++++++++++++++++++++++++++++++++++++

ALTER TABLE ONLY layer_epsg ADD CONSTRAINT pk_layer_epsg PRIMARY KEY  (fkey_layer_id,epsg);

++++++++++++++++++++++++++++++++++++++
layer style has to be cleaned, but I think the pk should be like this. but I'm not sure!:
++++++++++++++++++++++++++++++++++++++
ALTER TABLE ONLY layer_style ADD CONSTRAINT pk_layer_style PRIMARY KEY  (fkey_layer_id,name);







Gruß,
Marko


Marko Samson
Landesbetrieb Wald und Holz NRW
GIS-Anwendungsentwicklung
Referat I-5
Albrecht-Thaer-Straße 34
48147 Münster


Achtung, neue Telefonnummer!
Tel.: 0251/91797 - 169
Mail: marko.samson at wald-und-holz.nrw.de
 

> -----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: Mittwoch, 31. Januar 2007 08:23
> An: Mapbender Developer List
> Betreff: Re: [Mapbender-dev] PKs for all tables?
> 
> Hi Marko,
> 
> Samson, Marko schrieb:
> >> -----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?
> 
> You're right. But we have some more GeoDataExplorer, for 
> example the configurable one... Howerver, if we don't need to 
> publish layer twice, we should have a unique fkey_wms_id - 
> fkey_layer_id combination.
> 
> > 
> > But there are several tables without pks. I think, for a 
> stable datastructure it is advantageous to have pks at every table. 
> 
> That's definitively true. Is someone able to list the missing 
> pks and to create the corresponding sql-statements, if all 
> dev-members agree?
> 
> Thanks for your hints Marko and best regards Uli
> 
> > 
> > _______________________________________________
> > Mapbender_dev mailing list
> > Mapbender_dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapbender_dev
> 
> 
> --
> ---------------------------------
>         Ulrich Rothstein
>     WhereGroup GmbH & Co.KG
>         Siemensstraße 8
>          53121 Bonn
>            GERMANY
> ---------------------------------
>     uli.rothstein at wheregroup.com
>           uli at osgeo.org
>         www.wheregroup.com
>         www.mapbender.org
> ---------------------------------
> Zentrale:  ++49 (0) 228 909038 0
> Durchwahl: ++49 (0) 228 909038 17
> Fax:       ++49 (0) 228 909038 11
> ---------------------------------
> 
> ACHTUNG: Die Firmen Geo-Consortium, CCGIS und KARTA.GO haben 
> ihre Fusion als WhereGroup zum 1.1.2007 bekannt gegeben.
> Daher ändern sich ab Januar 2007 die Email Adressen und 
> Telefonnummern.
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: layer_epsg.zip
Type: application/x-zip-compressed
Size: 26997 bytes
Desc: layer_epsg.zip
Url : http://lists.osgeo.org/pipermail/mapbender_dev/attachments/20070131/ede38d82/layer_epsg-0001.bin