Bonjour à tous,
Petite question lors de la conception d'une BDD d'une application ayant un traffic et un volume de données importants.
Cette application gère des petites annonces de véhicules de type différents (voiture, voiture sans permis, moto, vélo, trotinette, brouette :aie:, etc).
L'accès principales aux annonces se fait via une recherche qui portera soit sur tous les véhicules peu importe le type, soit sur un type particulier de véhicule.
La recherche se fait uniquement sur le nom du véhicule.
Donc soit je décide de rechercher Honda dans Tous les véhicules, soit Honda dans Moto par exemple.
Je me demande au niveau de la BDD si je dois faire un niveau d'abstraction du style :
1 table véhicule qui contiendra le type (VOITURE, MOTO, etc), le nom pour faire la recherche, les infos communes aux véhicules (nb de places etc) et une FK pour récupérer les infos des tables spécifiques ("Voiture", "Moto", "Vélo" qui contiendront les informations spécifiques à la catégorie).
Ou si je pars sur 1 table pour chaque type (1 table voiture, 1 table moto) avec pour chaque table une colonne nom, avec une vue ayant le nom de tous les véhicules pour faciliter ma recherche par nom toutes catégories confondues.
Ou si j'utilise la notion d'héritage présente dans PGSQL (INHERITS).
Générer une notion d'héritage au niveau du modèle est-il pénalisant pour les performances de lecture/écriture ?
Soyons fous (mais trop quand même), en disant que chaque table fille contient 100k enreg, ce qui donne notre table Vehicule à 1M enreg (partons sur 10 tables filles donc).
L'objectif principal est d'avoir une recherche multi catégories, et une recherche par catégorie.
Dans l'appli j'ai ma recherche multi catégorie qui prend donc en paramètre "nomVehicule" qui va me donner une query qui va fouiller les 1M d'enreg du type :
SELECT id FROM Vehicule v WHERE v.nom ILIKE '%nomVehicule%'
ou par catégorie :
SELECT id FROM Vehicule v WHERE v.nom ILIKE '%nomVehicule%' and v.type = 'VOITURE'
Est-ce suffisamment performant ou faut-il envisager les autres solutions décrites plus haut ?
Merci pour vos lumières :merci:
Petite question lors de la conception d'une BDD d'une application ayant un traffic et un volume de données importants.
Cette application gère des petites annonces de véhicules de type différents (voiture, voiture sans permis, moto, vélo, trotinette, brouette :aie:, etc).
L'accès principales aux annonces se fait via une recherche qui portera soit sur tous les véhicules peu importe le type, soit sur un type particulier de véhicule.
La recherche se fait uniquement sur le nom du véhicule.
Donc soit je décide de rechercher Honda dans Tous les véhicules, soit Honda dans Moto par exemple.
Je me demande au niveau de la BDD si je dois faire un niveau d'abstraction du style :
1 table véhicule qui contiendra le type (VOITURE, MOTO, etc), le nom pour faire la recherche, les infos communes aux véhicules (nb de places etc) et une FK pour récupérer les infos des tables spécifiques ("Voiture", "Moto", "Vélo" qui contiendront les informations spécifiques à la catégorie).
Ou si je pars sur 1 table pour chaque type (1 table voiture, 1 table moto) avec pour chaque table une colonne nom, avec une vue ayant le nom de tous les véhicules pour faciliter ma recherche par nom toutes catégories confondues.
Ou si j'utilise la notion d'héritage présente dans PGSQL (INHERITS).
Générer une notion d'héritage au niveau du modèle est-il pénalisant pour les performances de lecture/écriture ?
Soyons fous (mais trop quand même), en disant que chaque table fille contient 100k enreg, ce qui donne notre table Vehicule à 1M enreg (partons sur 10 tables filles donc).
L'objectif principal est d'avoir une recherche multi catégories, et une recherche par catégorie.
Dans l'appli j'ai ma recherche multi catégorie qui prend donc en paramètre "nomVehicule" qui va me donner une query qui va fouiller les 1M d'enreg du type :
SELECT id FROM Vehicule v WHERE v.nom ILIKE '%nomVehicule%'
ou par catégorie :
SELECT id FROM Vehicule v WHERE v.nom ILIKE '%nomVehicule%' and v.type = 'VOITURE'
Est-ce suffisamment performant ou faut-il envisager les autres solutions décrites plus haut ?
Merci pour vos lumières :merci:
Aucun commentaire:
Enregistrer un commentaire