Форматировать данные до или после вставки в базу данных?

Question

Я никогда не могу решить, лучше ли форматировать данные перед вставкой в ​​БД или при извлечении.

Я не говорю о санации данных; мы все знаем, как защитить от внедрения SQL. Я говорю о том, что если пользователь дает вам URL, и перед ним нет http: //, следует ли добавить его перед вставкой в ​​БД или при извлечении? Как насчет более сложных вещей, таких как форматирование большого текста. Хочу ли я пометить его HTML (или вырезать) до или после? Что если я передумаю позже и захочу отформатировать его по-другому? Я не могу сделать это, если я уже отформатировал это, но я могу, если я храню это в неформатированном виде ... но тогда я делаю дополнительную работу каждый раз, когда я вытаскиваю часть данных из БД, которую я мог бы иметь сделано один раз и было сделано с ним.

Что ты думаешь?

---

Судя по ответам, существует общее мнение, что такие вещи, как URL-адреса, телефонные номера и электронные письма (что-либо с четко определенным форматом) должны быть сначала нормализованы до согласованного формата. Такие вещи, как текст, как правило, должны быть оставлены в необработанном виде или в управляемом формате для максимальной гибкости. Если скорость является проблемой, оба формата могут быть сохранены.

Answer 1

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

Answer 2

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

Чтобы избежать ненужной постобработки в каждом запросе, вы можете рассмотреть вопрос о применении кеширования объектов или подобных методов для более дорогих операций.

Answer 3

Вы задаете два вопроса здесь.

Нормализация всегда должна выполняться до вставки базы данных, например если в столбце есть только URL-адреса, то их всегда следует сначала нормализовать.

Что касается форматирования, это проблема представления, а не проблема модели (в данном случае БД).

Answer 4

Возможно, вы захотите сохранить как отформатированные, так и неформатированные версии данных. Например, давайте использовать американские номера телефонов в качестве примера. Если вы храните один столбец только с числами и один столбец с наиболее часто используемым форматом, таким как (111) 111-1111, то вы можете легко отформатировать до спецификаций клиента для особых случаев или быстро извлечь наиболее общий из них без лотов литья. Это занимает очень мало дополнительного времени во время вставки (и может быть выполнено с помощью вычисляемого столбца, поэтому это всегда происходит независимо от того, откуда поступили данные).

Данные должны быть очищены перед помещением в базу данных, чтобы недопустимые даты или нечисловые данные и т. Д. Никогда не помещались в поле. Электронная почта - это одна из областей, в которую люди часто по какой-то причине кладут мусор. Если у него нет знака @, его не следует хранить. Это особенно верно, если вы действительно отправляете электронные письма через ваши приложения, используя это поле. Попытка отправить электронное письмо с просьбой «связаться с его секретарем» или «aol.com» - пустая трата времени, если вы понимаете, о чем я.

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

Answer 5

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

Это та же самая причина, по которой существуют векторные форматы графики (SVG, EPS и т. Д.): Файл SVG, по сути, представляет собой последовательность инструкций, определяющих способ рисования изображения. Это легко преобразовать в растровое изображение любого размера, в то время как если бы у вас было только растровое изображение, вам было бы трудно изменить его размер (например, создать эскиз) без потери качества.

Answer 6

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

Answer 7

зависит от

если вы выполняете четко определенные элементы, SSN, почтовый индекс, номер телефона, сохраняете их в формате (это не обязательно означает, что нужно добавить тире или точки и т. Д., Это может означать их удаление, чтобы все было согласованно)

Answer 8

На мой взгляд, сначала его нужно отформатировать. Если вы решите сделать это во время извлечения вместо вставки, это может вызвать проблемы в будущем, когда другие приложения / скрипты захотят использовать данные из той же базы данных. Им всем нужно знать, как очистить данные, когда они их извлекают.