Нужно мнение эксперта по дизайну базы данных

Question

Буду признателен советам экспертов по схеме базы данных для веб-сайта.

У меня есть дизайн базы данных для сайта объявлений, который в настоящее время выполняется в движке MyISAM, поэтому нет никаких связей, ключей и т. Д.

Пожалуйста, посмотрите на модель ER для текущего дизайна:

Мне нужно знать, нахожусь ли я на правильном пути с дизайном БД ... (Поля «Email» и «Password» являются избыточными в таблицах «Users» и «Ads», поскольку первый план не требовал регистрации пользователя, но этот план был изменилось в последнее время. Поэтому, пожалуйста, игнорируйте этот бит, так как я удалю эти поля из таблицы объявлений)

Ожидается, что сайт может выполнять как минимум 100 000 просмотров страниц в день в течение нескольких месяцев с момента запуска.

Пожалуйста, посоветуйте, что вы думаете об этом дизайне и что можно сделать лучше.

Также, пожалуйста, посоветуйте лучший движок Db для использования на таком сайте (InnoDb или любой другой ...).

Посоветуйте, пожалуйста, какой механизм хранения данных лучше всего подходит для этой базы данных, учитывая производительность, нагрузку, целостность базы данных (если это необходимо, поскольку в настоящее время она разработана для механизма MyISAM и, следовательно, отсутствие целостности базы данных), и все, что нужно учитывать такой сайт.

Я знаю, что конкретные проблемы / проблемы с базой данных могут быть решены только тогда, когда они возникают в реальности, но, по крайней мере, я хочу начать в правильном направлении.

Заранее спасибо за вашу помощь.

Answer 1

С первого взгляда. , .

Мы не можем видеть первичные ключи, уникальные ограничения или что-то подобное на вашей диаграмме. Их отсутствие беспокоит.

Почти каждая таблица имеет идентификационный номер. Некоторые из них просто называются «id», а другие имеют более описательное имя. Более описательный - лучшее из этих двух идей.

Идентификационный номер в таблице, который не имеет других уникальных ограничений, обычно является ошибкой. (Обычно, но не всегда.) Например, для таблицы "cats", вероятно, требуется уникальное ограничение для "catname". В противном случае идентификационный номер будет идентифицировать только строку, а не кошку. (А это значит, что у вас может быть две или более строки с одним и тем же "catname".)

Таблицы adxfields и subcatxfields выглядят как катастрофа, ожидающая возможности. Таблица 'subcatxfields' выглядит как некий EAV-шаблон. Внимательно посмотрите на слайд-шоу Билла Карвина по анти-шаблонам базы данных , прежде чем идти по этому пути. (EAV начинается на слайде 16.)

Цены на Subcat, вероятно, следует перенести в отдельную таблицу.

Существует международный стандарт для кодов стран . Вам лучше использовать стандартные коды стран, а не свой собственный идентификационный номер. Использование удобочитаемого кода означает, что вы обычно можете исключить соединение. (Обычно, но не всегда.)

В таблице "города" не хватает столбцов для определения города. (В США много городов с названием "Вашингтон".)

Достаточно времени. , .

Answer 2

1. Почему бы вам использовать MyISAM? Из того, что я вижу, вы не говорите о высокопроизводительном веб-сайте, так зачем его использовать ??? Перейти с InnoDB.

2. Целостность данных не вариант, поэтому, если вы не эксперт, вы, вероятно, не задумывались о реализации логики для нее в своем приложении, поэтому вам действительно стоит подумать об использовании FK.

3. Только глядя на вашу модель ER (которая даже не является ERM, поскольку у вас нет определенных отношений, поэтому нет R, это скорее EM), мы не можем сказать все это слишком много. Нам нужна история, и история кажется большой.

4. 100 000 хитов в день - это арахис, и в этом случае вводит в заблуждение. Какова самая высокая ожидаемая скорость в секунду? Как долго должно быть возможно поддерживать этот уровень?

5. В этой модели также отсутствуют типы данных. Они не являются обязательными даже для минимального анализа.

6. Что-то подобное обычно занимает несколько дней, чтобы обсудить и проанализировать, я нахожу это немного за гранью, особенно учитывая нехватку информации.