Avis d'expert requis sur la conception de la base de données

Question

J'apprécierais les conseils d'experts sur un schéma de base de données pour un site Web.

J'ai une conception de base de données pour un site de listes de petites annonces qui se fait actuellement dans le moteur MyISAM donc il n'y a pas de relations, les clés, etc.

S'il vous plaît consulter le modèle ER pour la conception actuelle:

Je dois savoir si je suis sur la bonne voie avec le DB design ... (les champs e-mail et mot de passe sont redondants dans les deux utilisateurs et les annonces de tables En effet, le premier plan n'était pas d'exiger l'enregistrement des utilisateurs, mais ce plan a été modifié récemment. Donc, s'il vous plaît ignorer ce bit puisque je vais supprimer ces champs du tableau annonces)

On s'attend à ce que le site a le potentiel de faire au moins un minimum de 100 000 pages vues par jour dans quelques mois à compter du lancement.

S'il vous plaît des conseils sur ce que vous pensez de cette conception et ce qui pourrait être fait mieux.

En outre s'il vous plaît des conseils sur le meilleur Db Engine à utiliser pour un tel site (InnoDb ou tout autre ...). Veuillez indiquer le meilleur moteur de stockage pour cette base de données en tenant compte des performances, de la charge et de l'intégrité de la base de données (si nécessaire car il est conçu pour le moteur MyISAM et donc pas d'intégrité Db). pour un tel site.

Je sais que les problèmes/problèmes de bases de données spécifiques ne peuvent être traités que lorsqu'ils se produisent réellement, mais au moins je veux commencer dans la bonne direction.

Merci d'avance pour toute votre aide.

Answer 1

1. Pourquoi pourquoi utiliser MyISAM? D'après ce que je vois, vous ne parlez pas d'un site Web de haute performance, alors pourquoi l'utiliser? Aller avec InnoDB. L'intégrité des données n'est pas une option, donc si vous n'êtes pas un expert, vous n'avez probablement pas pensé à implémenter la logique dans votre application, alors vous devriez vraiment envisager d'utiliser FK. Si l'on ne regarde que votre modèle ER (qui n'est même pas un ERM puisque vous n'avez aucune relation définie, donc il n'y a pas de R, c'est plus un EM), nous ne pouvons pas tout dire. Nous avons besoin d'une histoire, et l'histoire semble grande.

2. 100k coups par jour est des arachides et dans ce cas trompeur. Quel est le taux le plus élevé prévu par seconde? Pendant combien de temps doit-il être possible de maintenir ce niveau?

3. Il manque également les types de données pour ce modèle. Ceux-ci ne sont pas facultatifs même pour des analyses minimales. Quelque chose comme ça prend habituellement des jours à discuter et à analyser, je trouve cela un peu exagéré ici, surtout étant donné la rareté de l'information.

Answer 2

En un coup d'œil. . .

Nous ne pouvons pas voir les clés primaires, les contraintes uniques ou quoi que ce soit de ce genre dans votre diagramme. Leur absence est troublante.

Presque chaque table a un numéro d'identification. Plusieurs d'entre eux sont simplement appelés "id", et d'autres ont un nom plus descriptif. Plus descriptif est le meilleur de ces deux idées.

Un numéro d'identification dans une table qui n'a pas d'autres contraintes uniques est généralement une erreur. (Habituellement, mais pas toujours.) Par exemple, la table "chats" a probablement besoin d'une contrainte unique sur "catname". Sinon, le numéro d'identification identifiera seulement une rangée, pas un chat. (Et cela signifie que vous pouvez avoir deux lignes ou plus avec le même "catname".)

Les tableaux adxfields et subcatxfields ressemblent à une catastrophe en attente d'opportunité. La table 'subcatxfields' ressemble à une sorte d'anti-pattern EAV. Regardez attentivement au Bill Karwin's slideshow on database anti-patterns avant de prendre cette route. (EAV commence à la diapositive 16.)

La tarification du sous-abonnement devrait probablement être déplacée vers une table distincte.

Il y a un international standard for country codes. Il est préférable d'utiliser les codes de pays standard au lieu de votre propre numéro d'identification. L'utilisation d'un code lisible par l'utilisateur signifie que vous pouvez généralement éliminer une jointure. (Habituellement, mais pas toujours.)

La table "villes" n'a pas assez de colonnes pour identifier une ville. (Il y a beaucoup de villes nommées «Washington» aux États-Unis.)

C'est assez de temps. . .