2010-06-04 8 views
0

Je travaille sur un site immobilier et j'ai besoin de faire un mailing de notification: quand une nouvelle propriété est insérée sur un site, les personnes qui ont souscrit une notification dans ce pays et/ou cette région et/ou ville et/ou opération immobilière particulière (location, vente) recevra une notification par email. Une personne peut s'abonner pour différentes zones, villes, etc., pas seulement une. Une personne ne recevra qu'une seule notification par semaine, disons s'il y a de nouvelles propriétés pour lui. Et je pense à comment mieux créer une table mysql pour les abonnés afin de les récupérer facilement. Tableau comme:Aide avec php/mysql mailer

create table subscribers(
user_email varchar(255), 
area_id int(4)); 

est une mauvaise idée, parce que si on va laisser dire 100 000 (regardant vers l'avenir) abonnés et chacun souscrira 10 zones, il y aura 1.000.000 lignes d'une table. Donc, je cherche une solution efficace pour faire une telle tâche.

Si vous avez d'autres recommandations, j'aimerais les entendre.

Merci d'avance!

Répondre

1

Vous devez utiliser une table de références croisées (plusieurs-plusieurs). Cela rendra les données plus normalisées:

CREATE TABLE `areas` (
    `id` int(10) unsigned NOT NULL auto_increment, 
    `name` varchar(255) NOT NULL 
    PRIMARY KEY (`id`) 
) 


CREATE TABLE `subscribers` (
    `id` int(10) unsigned NOT NULL auto_increment, 
    `email` varchar(255) NOT NULL 
    PRIMARY KEY (`id`) 
) 


-- cross ref table 
CREATE TABLE `areas_subscribers` (
    `area_id` int(10) unsigned NOT NULL, 
    `subscriber_id` int(10) unsigned NOT NULL, 
    UNIQUE KEY (`area_id`,`subscriber_id`) 
) 

Et un million de lignes n'est pas un problème. Surtout avec une table de croisement.

+0

J'ai toujours craint de grandes tables, car elles devraient avoir une optimisation supplémentaire ou elles seront plutôt lentes. Chaque fois que j'essaie d'éviter plusieurs lignes avec les mêmes données (dans ce cas, le courrier électronique) en mettant en œuvre des algorithmes complexes. – Starmaster

+0

Ce schéma prendra soin de cela. Faire une table de références croisées comme ceci signifie que seulement deux champs entiers sont utilisés. Nice et compact. De plus, ils sont indexés pour que les recherches soient rapides. – webbiedave

0

il y aura 1.000.000 lignes dans une table

Alors quoi? mySQL can handle it. Autant que je puisse voir, la façon dont vous le faites est parfaitement bien. C'est bien normalisé, je ne peux pas penser à une meilleure méthode.

0

Votre tableau semble correct, en supposant que user_email est la clé primaire identifiant vos utilisateurs. Si c'est le cas, ajoutez à votre table subscribers un PRIMARY KEY (user_email, area_id) pour indiquer que les deux champs forment ensemble votre clé primaire. Votre souci concernant la duplication des e-mails a peu à voir avec la conception du schéma et plus avec la requête que vous voulez exécuter. Cela, bien sûr, dépendra en grande partie sur la façon dont vos autres données sont stockées, mais pourrait ressembler à: (. Pour une liste des area_id valeurs qui ont vu les annonces de la semaine dernière)

SELECT DISTINCT user_email WHERE area_id IN (...) 

C'est une requête simple qui pourrait être optimisée et améliorée compte tenu du reste de votre schéma, mais cela illustre à quel point il est facile d'éviter de générer plusieurs e-mails malgré le fait que la même personne soit listée plusieurs fois.

0

Vous pouvez créer un tableau supplémentaire des adresses électroniques. Ainsi, vous ne stockez qu'un ID dans la table d'abonné et pas toujours la même adresse électronique (alors qu'il peut y avoir quelques optimisations dans la base de données).