Quelle est la solution idéale pour stocker plusieurs ID dans une table de base de données?

Question

Mon application immobilière dispose d'une table de base de données contenant les requêtes (requêtes) de l'utilisateur. Cette table contient toutes les informations sur une requête immobilière particulière.

La table de base de données ressemble à ceci:

CREATE TABLE IF NOT EXISTS `queries` (
    `id` bigint(20) NOT NULL auto_increment, 
    `category_id` int(10) NOT NULL, 
    `serial` varchar(30) NOT NULL, 
    `minBudget` int(11) NOT NULL, 
    `maxBudget` int(11) NOT NULL, 
    `city_id` int(10) NOT NULL, 
    `area_id` int(10) NOT NULL, 
    `locality` varchar(100) NOT NULL, 
    `status` tinyint(1) NOT NULL, 
    PRIMARY KEY  (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

Dans city_id et les chances sont area_id il y a des situations où je voudrais stocker plusieurs ID; par exemple, 10, 12, 20, 50 et ainsi de suite.

Comment dois-je stocker ceci dans les données?

Dois-je utiliser le type de données varchar et le maintenir comme une chaîne avec un délimiteur défini, puis extraire la valeur dans un tableau? Ne pas utiliser un varchar si ceux-ci sont des ID à une autre table.

Answer 1

Utilisez un tableau plusieurs-à-plusieurs les mappant ensemble.

CREATE TABLE IF NOT EXIST `query_cities` (
`id` bigint(20) NOT NULL auto_increment, 
`query_id` bigint(20), 
`city_id` bigint(20) 
) 

CREATE TABLE IF NOT EXIST `query_areas` (
`id` bigint(20) NOT NULL auto_increment, 
`area_id` bigint(20) 
) 

Ce sera beaucoup plus propre que la farce des choses dans un varchar - par exemple, il vous permet de dire:

SELECT c.city_name, c.state, c.whatever FROM queries q 
JOIN cities c ON (q.city_id = c.id) WHERE q.id = ? 

Edit: meh, je suis boiteux et ne comprend pas les clés étrangères , là, mais vous avez compris.

Answer 2

Vous pouvez le faire, mais ce n'est pas vraiment la solution préférée. C'est le compromis classique dans la normalisation de base de données. L'approche "plus correcte" consiste à avoir des tables "cities" et "areas", et des tables "queries_cities" et "queries_areas" qui sont plusieurs-à-plusieurs pour les relier. Sinon, que se passe-t-il si un identifiant de ville ou de zone change? Plutôt que de modifier un seul enregistrement au même endroit, vous devrez écrire un script pour parcourir et mettre à jour manuellement tous les enregistrements de requête.