Как хранить в БД большой отформатированный текст?

Question

[# a r t u r #]

Здравствуйте!

Появилась нужда хранить в таблице большой отформатированный текст (содержимое счёт-фактур), таблица очень простая:

id (int) | description (?)

Нет возможности содержимое description оформлять при выводе. Хочу хранить сразу с html-тегами.

Заносить информацию в данную таблицу будет отдельная функция в которую будут поступать только переменные БЕЗ каких-либо тегов и тд.

Какой тип данных выбрать? Насколько это безопасно и правильно?

PS: нужда появилась в процессе написания интернет-магазина в котором товары и категории будут постоянно удаляться/переименовываться и необходимо выдавать корректную информацию о давних заказах. Т.е. в description будут попадать наименования товаров, их количества, суммы на момент оплаты заказа и все это будет оформлено в виде "легкой" таблицы, и сохранено под уникальным ID заказа.

Comments

[YemSalat]

longtext?

[YemSalat]

Но вообще я бы посоветовал создать отдельную табличку для "старых" заказов, и записывать туда не просто хтмл, а все параметры по отдельности в столбцах. Что если например в будущем потребуется функционал учета или переоформления старых заказов? Как будете все это из хтмл вытаскивать?

[# a r t u r #]

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

[YemSalat]

Артур Селиванов: по вашему хранить полностью хтмл заказов - менее ресурсоемко?
Можно вместо удаления товаров помечать их как удаленные и хранить только айдишники в таблице старых заказов, можно дублировать данные (если нужно сохранить информацию о старой цене и т.д. необязательно дублировать все, только то что важно)
Оба этих подхода кажутся мне лучше чем хранить хтмл.

[# a r t u r #]

YemSalat: "Можно вместо удаления товаров помечать их как удаленные и хранить только айдишники" - так делаю сейчас, НО:

Очень много связей:
- связанные товары
- категории в которых отображается товар
- изображения относящиеся к товару
- заказы в которых упоминается товар

Тип таблицы InnoDB, хочется определить внешние ключи и затирать все связи в случае удаления определенного товара на уровне БД, это поможет избавиться от груды кода и сохранить целостность, ведь если удаляется Категория с Субкатегориями удобнее затереть все товары в них и связи, чем ставить для товаров статус "Удален", а потом еще и затирать связи грудой запросов.

Не хочется хранить удаленные товары, ведь если его удалил - да именно УДАЛИЛ, а не пометил "нет в наличии" или "отключен", то о каком маркетинге, учете и переоформлении может идти речь?

Возможно я неправильно мыслю, если так то поправьте, именно из-за сомнения решил обратиться к вам.

[# a r t u r #]

YemSalat: Проблема а скорее "некрасивая" часть фактического удаления заключается в том, что старые заказа в случае удаления каких -то товаров будут отличаться от счет-фактур (

[YemSalat]

Артур Селиванов: Мне кажется что в рамках вашего примера лучше все-таки помечать. Категории в том числе.
Удаление категории же не обязательно означает удаление всех ее товаров. Они могут просто быть "uncategorized" в случае если категория помечена как неактивная.
Количество запросов будет одинаковым, просто вместо DELETE будет UPDATE.

Больше ничего сказать не могу, все зависит от конкретных задач.

Answer 1

[Philipp]

LONGTEXT, при грамотном подходе абсолютно безопасно, т.к. контент создаете вы.
Насчет правильно вопрос сложный, т.к. зависит от постановки задачи.
Обычно такие вещи генерируют на лету и хранят состав заказа. Всякие маркетологи любят спросить, а что было в тренде в мае прошлого года. Ну и всякие ABC-анализы нужны и т.п., отчеты о продажах с разрезами.

Comments

[# a r t u r #]

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

[Сергей Сенкевич]

@Артур Селиванов У вас неправильно хранится состав сделанного заказа. После того, как заказ был сделан, его данные перемещаются в таблицы с историческими данными, т.е. данными, которые больше не будут меняться. В этих таблицах не должно быть внешних связей с таблицей текщих товаров, только копии полей "Наименование", "Количество" и "Стоимость". Как правило, таких таблиц две - одна с "шапкой" заказа (дата, общая сумма, вид доставки, вид оплаты, кто сделал заказ и т.д.), а другая содержит строки заказа. А счет-фактуру надо просто сгенерировать и сохранить в виде файла на сервере. Ссылку на файл сохранить в "шапке" заказа.

[# a r t u r #]

Сергей Сенкевич: Шикарно. Щас в душе полоскался и тоже самое в голову пришло. Шикарно. Спасибо.

Кстати, перед тем как перенести заказ в таблицу "завершенных заказов" из основной таблицы его лучше удалить?

[Сергей Сенкевич]

Артур Селиванов Я обычно удаляю).

Answer 2

[Владимир Коршунов]

Я в своё время сохранял именно корзину на момент оформления заказа. Прошла оплата, зафиксировал данные (цена, количество, наименование, номер заказа, доставка и прочее).

Если реляционная БД, то переносил данные в отдельные 2 таблицы (первая информацию о заказе хранит, а вторая хранит позиции из корзины). Потом перешёл на MongoDB и это одна запись в коллекции.

Почему так — иногда дизайн (как вид, так и поведение) меняется, надо переделывать, и в данном случае проще просто отрендерить страницу. Например для письма, для вывода на экран, для API и для печати.