Организация реляционных баз данных

Question

Я создаю CMS для сайта, который будет содержать новости и различные темы для новостных страниц. Поэтому я создавал одну таблицу для каждой темы (спорт, литература и т. Д.), Чтобы иметь более чистую и лучшую организацию баз данных (я думал). Но я недавно узнал о реляционных базах данных и выяснил, что можно достичь той же задачи с меньшим количеством таблиц (всего 2 темы и содержимого таблиц) и, следовательно, меньше кода (что отлично). Но моя забота заключается в том, что, поскольку этот веб-сайт со временем может иметь сотни или, может быть, тысячи страниц, безопасно, чисто и нормально иметь столько страниц в одной таблице? Зная, что когда-нибудь кто-то может взломать сайт и ПОКАЗАТЬ этот стол, и я потеряю все сообщения. Итак, есть ли более чистый и безопасный способ для решения этой задачи, но при этом используется концепция реляционных баз данных?

Answer 1

Короткий ответ: Да. Как говорит JLo в комментарии выше, при разработке структуры базы данных вы не должны думать главным образом о безопасности; В основном, речь идет об эффективности хранения данных (т.е. нормализации).

Если хакер может попасть в вашу базу данных, это проблема, независимо от того, какие таблицы они могут получить. Поэтому с точки зрения безопасности, сосредоточьте свою энергию на предотвращении инъекций и нападений базы данных в первую очередь. Чтобы попытаться разделить ваши данные на разные таблицы, чтобы защитить их от хаков, это как хранить золото в десяти разных хранилищах банков для защиты от ограблений банков; это security through obscurity, и он работает против вас на каждом шагу.

Вместо этого, с точки зрения безопасности:

• Инвестируйте в аудит безопасности для кода сервера, если он уже написан. Эксперт может указать вам на фрагменты кода, которые могут иметь последствия для нежелательного доступа к базе данных и точно указать, почему. Я бы сказал, что опыт обучения, который вы получаете от аудита, еще более ценен, чем конкретные конкретные рекомендации, которые они делают.
• Google SQL injection и прочитайте все, что возможно, по теме. Эта методика заключается в том, как происходит большинство хабов базы данных, и очень важно, чтобы вы были более чем знакомы с тем, что это такое, какой уязвимый код выглядит и как писать код, который защищает его.
• Настройте отличные резервные системы резервирования баз данных. Не менее 2 отдельных сохраненных в 2 разных местах. Если какой-либо из хакеров взломает одну из ваших таблиц, то это станет основным неудобством, а не бизнес-прерывателем.

В терминах нормализованной strucutre данных:

• магазин одни и те же данные в форме, в том же месте. До тех пор, пока все страницы могут быть описаны/определены в терминах одних и тех же столбцов в таблице, полностью сохраните их в одной таблице.
• Узнайте о показателях и индексах Mysql. Плохо проиндексированная/плохо структурированная база данных может останавливаться при низком трафике и менее миллиона строк в крупнейших таблицах; хорошо проиндексированный может вести себя хорошо с миллиардами строк. Эта проблема становится больше по мере увеличения трафика, поэтому, надеюсь, ваш бюджет растет соответственно и позволяет вам получить экспертную помощь по этому вопросу. Проблемы с производительностью могут внезапно поднимать голову, поэтому стоит много узнать о них, прежде чем они разбивают ваш сайт.
• Не беспокойтесь о количестве строк. Основная проблема здесь - производительность; см. выше. Реляционные базы данных созданы для обработки больших таблиц; это их основной вариант использования. С базовыми методами индексирования (например, добавьте индекс в каждый столбец внешнего ключа и любой другой столбец, который обычно запрашивается против (но столбцы первичного ключа уже проиндексированы, поэтому они не нужны)), вы должны иметь возможность сделать это до 1M- 10M без серьезных проблем с производительностью.
• Найдите способ сравнения ваших запросов с реальными данными. Некоторые оптимизации производительности очевидны, но, как говорится, premature optimization is the root of all evil. Например, при написании своих запросов выполните некоторые экспериментальные эксперименты, чтобы понять, более ли важно иметь меньше запросов (которые больше/имеют больше JOIN) или более запросов (которые меньше и быстрее). Как правило, меньшее количество запросов лучше, но есть ряд случаев, когда ваше приложение не соглашается ;-) поэтому у вас есть инфраструктура, чтобы проверить ее самостоятельно. То же самое при добавлении индексов; бенчмаркинг может дать вам хороший смысл в отношении того, какие индексы воздействия имеют в вашей базе данных, и что смысл кишки - очень ценная вещь.

Answer 2

Поскольку этот сайт может со временем иметь сотни или, возможно, тысячи страниц, безопасно, чисто и нормально иметь столько страниц в одной таблице?

Пока ваши индексы верны, вы можете хранить миллионы страниц в базе данных.

Зная, что когда-нибудь кто-то может взломать сайт и отброшенных стол, и я бы развязывать все сообщения.

Использование одной или тысячи таблиц здесь не имеет значения, если вы можете отбросить один стол, вы можете бросить их все.