Почему создание таблиц во время выполнения (код позади) плохо? - PullRequest
7 голосов
/ 14 мая 2011

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

Я не вижу причин, почему, и я не вижу разницы между созданием таблицы и любым другим SQL-запросом / оператором, таким как SELECT или INSERT.Я написал приложения, которые создают, удаляют и изменяют базу данных и таблицы во время выполнения, и до сих пор я не вижу никаких проблем с производительностью.

Может ли кто-нибудь объяснить преимущества создания базы данных и таблиц во время выполнения?

Ответы [ 4 ]

3 голосов
/ 14 мая 2011

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

Теперь, если вы просто создадите одну или две и все, или всю базу данных динамически, или один раз из сценария, это может быть хорошо. Но если вы зависите от необходимости создавать все больше и больше таблиц для обработки ваших данных, вам также нужно будет присоединяться все больше и больше и запрашивать все больше и больше. Одна очень серьезная проблема, с которой я столкнулся в приложении, использующем динамическое создание таблиц, состоит в том, что один запрос SQL Server может включать только 255 таблиц. Это встроенное ограничение. (И это SQL Server, а не CE.) Потребовалось всего несколько недель для достижения этого предела, что привело к неработающему приложению.

А если вы приступите к редактированию таблиц, например, добавляя / удаляя столбцы, ваша головная боль от обслуживания становится еще хуже. Существует также вопрос привязки данных вашей базы данных к логике вашего приложения. Другая проблема заключается в обновлении производственных баз данных. Это действительно было бы проблемой, если бы БД динамически увеличивался с объектами, и вам вдруг потребовалось обновить модель.

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

2 голосов
/ 14 мая 2011

КМК,

Запомните следующие пункты

  1. Что, если вы хотите добавить или удалить столбец, вам нужно изменить код и скомпилировать его agian
  2. что если местоположение базы данных изменится
  3. Разработчики, которые не очень хорошо разбираются в базе данных, могут вносить изменения, если вы создаете схему на бэкэнде, администраторы базы данных могут позаботиться об этом.
  4. Если у вас возникнут проблемы с производительностью, отладка может оказаться сложной.
0 голосов
/ 14 мая 2011

иногда динамическое создание таблиц не является наилучшим вариантом с точки зрения безопасности (внедрение Google SQL), и было бы лучше использовать хранимые процедуры и выполнять операции вставки или обновления на уровне базы данных, выполняя хранимые процедуры в коде.

0 голосов
/ 14 мая 2011

Вам нужно будет немного яснее понять, что вы подразумеваете под «созданием таблиц».

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...