Luego de investigar por ahí creo que sé por dónde viene el error, aclarando que es mi primer proyecto que trabajo con postgresql y una de las cosas que me llamó la atención de este gestor es la psibilidad de particionar tablas, dejo una estructura más completa de lo que tengo, espero me orienten por favor:
Código SQL:
Ver originalCREATE TABLE tb_mat_materia
(
mat_id serial NOT NULL,
mat_materia CHARACTER VARYING(250),
CONSTRAINT tb_mat_materia_pkey PRIMARY KEY (mat_id)
)
WITH (
OIDS=FALSE
);
ALTER TABLE tb_mat_materia
OWNER TO admin;
CREATE TABLE tb_ing_materia
(
-- Inherited from table tb_mat_materia: mat_id integer NOT NULL DEFAULT nextval('tb_mat_materia_mat_id_seq'::regclass),
-- Inherited from table tb_mat_materia: mat_materia character varying(250)
)
INHERITS (tb_mat_materia)
WITH (
OIDS=FALSE
);
ALTER TABLE tb_ing_materia
OWNER TO admin;
CREATE TABLE tb_evals_evaluaciones
(
evals_id serial NOT NULL,
evals_eval_id INTEGER,
evals_fecha DATE,
evals_mat_id INTEGER,
evals_per_id INTEGER,
evals_prog_id INTEGER,
evals_hr_id INTEGER,
created_at TIMESTAMP(0) WITHOUT TIME zone NOT NULL,
updated_at TIMESTAMP(0) WITHOUT TIME zone NOT NULL,
CONSTRAINT tb_evals_evaluaciones_pkey PRIMARY KEY (evals_id),
CONSTRAINT tb_evals_evaluaciones_evals_hr_id_fkey FOREIGN KEY (evals_hr_id)
REFERENCES tb_hr_horario (hr_id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT tb_evals_evaluaciones_evals_mat_id_fkey FOREIGN KEY (evals_mat_id)
REFERENCES tb_mat_materia (mat_id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT tb_evals_evaluaciones_evals_per_id_fkey FOREIGN KEY (evals_per_id)
REFERENCES tb_per_personas (per_id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT tb_evals_evaluaciones_evals_prog_id_fkey FOREIGN KEY (evals_prog_id)
REFERENCES tb_prog_programas (prog_id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
OIDS=FALSE
);
ALTER TABLE tb_evals_evaluaciones
OWNER TO admin;
Como pueden observar tb_mat_materia es una tabla padre de tb_ing_materia, ahora bien, para poblar de datos incialmente lo he realizado por medio de inserts en la tabla tb_ing_materia y como es de esperarse al hacer un "select * from tb_mat_materia" se despliegan todos los registros incluído el registro 7.
Cosa que al ejecutar el:
Código SQL:
Ver originalINSERT INTO tb_evals_evaluaciones (evals_eval_id,evals_fecha,evals_mat_id,evals_per_id,evals_prog_id,evals_hr_id,updated_at,created_at)
VALUES (1, '10-02-2016', 7, 14, 1, 1, '2016-02-09 17:14:58', '2016-02-09 17:14:58')
Me devuelve:
Código SQL:
Ver originalERROR: inserción o actualización en la tabla «tb_evals_evaluaciones» viola la llave FORánea «tb_evals_evaluaciones_evals_mat_id_fkey»
DETALLE: La llave (evals_mat_id)=(7) no está presente en la tabla «tb_mat_materia».
es decir que aunque la inserción en la tabla padre la he realizado por medio de la tabla hija, la relación (llave primaria - foránea ) la hago directamente en la tabla padre porque cuando quise hacerla en la tabla hija no pude.
Creo que estoy aplicando mal el concepto de herencia de tablas. será que no debo crear relaciones en este caso?
De hecho la única forma que me funcionó el insert fue eliminar la restricción:
Código SQL:
Ver originalCONSTRAINT tb_evals_evaluaciones_evals_mat_id_fkey FOREIGN KEY (evals_mat_id)
REFERENCES tb_mat_materia (mat_id) MATCH SIMPLE
Viendo estoy creo que estoy concluyendo que no puedo ocupar llaves foráneas que son llaves primarias en tablas padres, en este caso sería de evaluar entonces a qué le doy más peso si a la integridad de los datos o la herencia?
me pueden orientar en este caso por favor?