Vous n'êtes pas identifié(e).
Pages : 1
Je suis partis sur du csv.
Je ferais pas de filtrage sur du csv si jamais le projet fonctionne bien il sera pas trop tard pour passer à de l'héritage ou pleins de tables si cela en vaut la peine.
Merci pour tout 
ok si je comprends bien une requête union all sur 100 tables c'est comme si je faisais 100 requêtes à la suite ?
Je sais pas encore si un attribut supplémentaire en csv avec les champs spécifiques est meilleur que 100 tables avec union all en terme de perf.
En terme de simplicité je pense le csv est largement plus facile à gérer.
Qu'en pensez vous ?
heu pardon par jointure j'entendais union all enfin un mécanisme pour rassembler les tables en fait. J'ai pas encore des connaissances très poussé en sql
C'est pas un problème pour la requète manuelle, une fois qu'elle est écrite ça va. Le problème c'est plutôt au niveau des perfs, ça va se passer comment la jointure sur 100 tables avec au maximum disont 15 enregistrements par table. Vous avez une idée ?
Oui et non car la vue commune pourra faire une différence suivant si l'offre vient de telle ou telle entreprise
Je souhaite répertorier des offres d'emplois.
Il y a des champs de base : Titre, Salaire, Adresse...
et des champs spécifiques aux entreprises : demandes particulières que je ne peux pas prévoir à l'avance, ca dépendra des entreprises qui seront indexés. (je sais pas si c'est clair)... En gros ce point est imposé par la spécification du projet.
Comme le nombre d'entreprise peut être très élevé je ne pas faire de jointure en cas de recherche sur tous les emplois.
Ca risque de ralentir la base si on fait une jointure avec environ 100 tables
Par contre le nombre de champs spécifique n'est pas égale dans toutes les tables, certains en ont 0 d'autre 5 etc ...
Bonjour,
je suis en train de faire une application qui me demande de passer par l'héritage. Pour simplifier, j'ai une table parent "produit" et beaucoup de tables (plus de 100) enfant "produit1 produit2 ..."
Je pourrais le gérer sans héritage avec des clé étrangére et des jointures mais c'est vraiment pas pratique et l'héritage simplifierait les choses.
De plus je ne sais pas si une jointure avec plus de 100 tables est très efficace...
Voici mon problème :
CREATE TABLE produit
(
id numeric NOT NULL,
"name" text,
CONSTRAINT "PK" PRIMARY KEY (id)
)
WITH (
OIDS=FALSE
);
ALTER TABLE produit OWNER TO postgres;
CREATE TABLE produit1
(
-- Geerbt from table produit1: id numeric NOT NULL,
-- Geerbt from table produit1: "name" text,
capacite numeric,
CONSTRAINT "PK2" PRIMARY KEY (id)
)
INHERITS (produit)
WITH (
OIDS=FALSE
);
ALTER TABLE produit1 OWNER TO postgres;
CREATE TABLE produiit2
(
-- Geerbt from table produiit2: id numeric NOT NULL,
-- Geerbt from table produiit2: "name" text,
epaisseur numeric,
CONSTRAINT "PK3" PRIMARY KEY (id)
)
INHERITS (produit)
WITH (
OIDS=FALSE
);
ALTER TABLE produiit2 OWNER TO postgres;INSERT INTO produiit2(
id, "name", epaisseur)
VALUES (2, 'planche', 18);
INSERT INTO produiit2(
id, "name", capacite)
VALUES (1, 'classeur', 100);Jusque l'à tout va bien.
Apres je veux faire un select :
SELECT *
FROM produit;j'obtiens :
1;"classeur"
1;"planche"
Ca semble cohérent.
Mais n'est il pas possible d'obtenir aussi les colonnes Capacité et épaisseur en sélectionnant la table produit et sans faire de jointures ?
Que j'obtienne cela :
1;"classeur";NULL;100
1;"planche";18;NULL
Sur le même principe j aimerais faire un select comme ceci sans jointure:
select * from produit where capacite =100mais bien sur écrit comme ceci il me dit que la colonne n'éxiste pas.
Est ce qu'une solution éxiste ou il faut passer par les jointures obligatoirement ?
Pages : 1