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

Question

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

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

Что вы думаете?

---

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

зависит

если вы делаете хорошо определенные элементы, ПЛА, почтовый индекс, номер телефона, сохраните его отформатированный (это не обязательно означает, что включать тире или точек и т.д., это может означать удаление их так everyhting является последовательно.

Answer 5

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

Answer 6

Здесь вы задаете два вопроса:

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

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

Answer 7

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

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

Answer 8

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

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

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