[SOLUCIONADO] Incluir primary key....¿cómo?

[dehm]

Me explico, a raíz de una duda colateral gnzsoloyo (al que no le voy a discutir una coma) me comentó que en una relación M:N no se han de poner claves primarias excepto en caso de que existiera la posibilidad de que hubiera un registro repetido.
Eso lo entendí, y lo entiendo como cosa lógica.

Pero tengo un caso concreto en el que requiero de una id única, y entonces no sé cómo hacerlo.

Mi caso es el siguiente:
Tengo dos grupos de parcelas, unas catastrales y otras pertenecientes a una comunidad, entre las cuales está esta relación M:N

El problema es que quiero trabajar con una Vista en Postgres (PostGIS) para visualizar las parcelas en un programa GIS (QGis en este caso), pero el programa me exige tener una clave primaria.

Entonces, ¿debería de poner en la tabla que relaciona unas parcelas con otras la clave primaria o hay una mejor solución para este caso?

Gracias como siempre, y siento ser tan pesado (también como siempre)

[mortiprogramador]

Saludo
Pues este es un caso especial, y toda regla tiene su excepción,
así que yo apoyo la moción de darle un id único en este caso
(Así gnzsoloyo quiera discutir el tema con QGis)

[gnzsoloyo]

Creo que hay un error de entendimiento...
Toda tabla debe forzosamente poseer una clave primaria (PK), y esta puede ser creada con un campo o atributo propio de la entidad representada, o bien se le agrega (solucion de programadores) con un campo ID numérico.
Un campo "ID" numerico no es obligatorio, ni es tampoco obligatorio que sea PK. NO es lo mismo.
Una PK es un campo o conjunto de campos que identifica univocamente un registro unico en una tabla, pero ese identificador no necesariamente es numérico ni incremental. Puede ser cualquier campo o conjunto de campos de la tabla que cumplan con la definicion.
Cuando digo que en una tabla relacional no se le agrega un campo adicional a menos que un par de claves pueda repetirse, pero ESE PAR DE CLAVES ES PK EN ESA TABLA. Eso creia que había quedado claro.
A lo que yo me refería es que si se da que una relación N:M pueda repetir una clave en dos registros obligatoriamente hay que poner un discriminante en esa tabla, y que el discriminante pasa a ser parte de la clave primaria
Vale decir, en ese contexto, una PK de una tabla relacional est'a compuesta de tres componentes: 1) La PK de la primera tabla.
2) La PK de la segunda tabla.
3) Un campo propio de la relación que permita discriminar cada uno de los registros que comparten las otras dos claves.

Ese tipo de clave primaria compuesta NO NECESARIAMENTE requiere campos numéricos. Depender'a del caso especifico de lo que se diseña, cual el el campo que se usara de discriminante.
¿Se entiende?

[dehm]

Iniciado por gnzsoloyo

Creo que hay un error de entendimiento...
Toda tabla debe forzosamente poseer una clave primaria (PK), y esta puede ser creada con un campo o atributo propio de la entidad representada, o bien se le agrega (solucion de programadores) con un campo ID numérico.
Un campo "ID" numerico no es obligatorio, ni es tampoco obligatorio que sea PK. NO es lo mismo.
Una PK es un campo o conjunto de campos que identifica univocamente un registro unico en una tabla, pero ese identificador no necesariamente es numérico ni incremental. Puede ser cualquier campo o conjunto de campos de la tabla que cumplan con la definicion.
Cuando digo que en una tabla relacional no se le agrega un campo adicional a menos que un par de claves pueda repetirse, pero ESE PAR DE CLAVES ES PK EN ESA TABLA. Eso creia que había quedado claro.
A lo que yo me refería es que si se da que una relación N:M pueda repetir una clave en dos registros obligatoriamente hay que poner un discriminante en esa tabla, y que el discriminante pasa a ser parte de la clave primaria
Vale decir, en ese contexto, una PK de una tabla relacional est'a compuesta de tres componentes: 1) La PK de la primera tabla.
2) La PK de la segunda tabla.
3) Un campo propio de la relación que permita discriminar cada uno de los registros que comparten las otras dos claves.

Ese tipo de clave primaria compuesta NO NECESARIAMENTE requiere campos numéricos. Depender'a del caso especifico de lo que se diseña, cual el el campo que se usara de discriminante.
¿Se entiende?

Hola:

Pues pido disculpas por dos cosas:
1.- Efectivamente, en mi falta de rigor he hecho una falsa identificación de una "tipica" columna Id con una PK. En el caso que me ocupa, mi tabla de relación puede funcionar perfectamente usando las dos columnas existentes como PK

2.- Eso me lleva al otro problema, que QGis me exige una ID. Y esto también es otro fallo clamoroso mío, puesto que averiguando un poco mas este fin de semana, veo que QGis me permite perfectamente que la "ID" esté compuesta por varias columnas, luego no he de andar creando una columna expresamente de ID para ello sino que le suministro la PK a partir de las columnas necesarias y punto(se puede hablar aquí de una falta de rigor del programa puesto que me debería pedir una "PK" pero así es como viene)


Como siempre saludos y gracias por la aclaración