Хорошо ли хранить serialize в БД?

Question

[S-a-n-d-r-0]

Недавно узнал о функциях serialize и unserialize в php. Таким способом можно записать целый массив в 1 ячейку таблицы sql, не создавая при этом дополнительной таблицы. Вопрос: нормальная ли это практика, стоит ли так делать и почему?

Comments

[Антон Р.]

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

Answer 1

[FanatPHP]

Ни в коем случае.
Твоя база данных не зря названа реляционной, то есть связанной. Информация хранится в связанных между собой таблицах. Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности. Что в миллион раз важнее лени "создавать дополнительную таблицу"

И не надо слушать советчиков из соседних ответов.
Увы, поколение милленниалов не умеет воспринимать письменный текст, и реагирует в лучшем случае на пару ключевых слов в вопросе, не воспринимая корнтекст. Который, чтобы было понятно, звучит так: Нашел у папы в сарае заряженнвую двустволку. Прикладом очень удобно орехи колоть. Это удобнее потому что из щипцов орехи вываливаются. Нормально ли колоть орехи заряженным ружьем?

Сериализованные данные стоит хранить в бд только в очень крайнем случае.
На данном этапе вообще забудь про такую возможность и учись работать с БД правильно.

Comments

[stilic]

Не надо слушать малолетних незнаек из соседних ответов.
...
Информация хранится в связанных между собой таблицах. Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности.

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

можно вам посоветовать все же прямо вашими же словами:

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

[Антон Р.]

Хорошо, а если у меня 5 видов пунктов меню в движке и у каждого вида свой набор настроек (полей), но в тоже время таблица Menu_items у меня одна и хранить пункты меню надо в ней.
Пример из реальности - пункты меню Joomla, там настройки как раз в одном поле params и сохраняются, в json.

[Daria Motorina]

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

[Дмитрий Свиридов]

Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности. Что в миллион раз важнее лени "создавать дополнительную таблицу"

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

[Владимир Коротенко]

FanatPHP , почитали одну книжку по теории РСУБД и раздаете советы одновременно глупые и категоричные.
База данных предназначена для решения бизнес задач. Нормализованная база данных в общем случае жуткий монстр. Так что в некоторых случаях лучше хранить метаданные в json. Типичный пример это слаботипизированные структуры, типа настроек плагина или метаданных документа.

[Barmunk]

Владимир Коротенко,

Нормализованная база данных в общем случае жуткий монстр

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

[FanatPHP]

Daria Motorina, что характерно, я разумеется угадал -автор ниже в комментах пишет что у него классическая 1 ко многим.

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

[Владимир Коротенко]

Barmunk, Все зависит от приложения. В общем случае я вообще стараюсь не хранить что то в БД.
Точнее даже не так. Есть базовый набор параметров, которые доступны в БД, все остальное взаимодействие происходит выше уровнем, DB layer или BL layer.
И ручками в sql вообще не лезть.

Но вы видимо спрашиваете про транзакции между 2 строками? Грубо говоря перевод с одного счета на другой?

[Дмитрий Свиридов]

Barmunk, а разве в случае "один ко многим" целостность как-то гарантируется в такой ситуации? Ничего не мешает в таблице с параметрами указать не все. Уровень вложенности более одного так тоже хранить особо не получится.

Да и при этом как использовать нормально limit и offset, если мне нужно получить список сущностей с их параметрами? Можно, конечно, делать 2 запроса: первый к таблице сущностей (с лимитом и оффсетом), потом взять их id и вторым запросом к базе через IN (список id сущностей) вытащить и их параметры, после чего на уровне кода все связать - но так ли уж это удобно? И как быть, если вложенность большая?

Answer 2

[Дмитрий Свиридов]

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

Comments

[FanatPHP]

да не требуется ему ничего. вы блин читать вообще умеете, хоть кто нибудь?

[stilic]

Во-первых, у mysql и postgresql для таких данных есть специальное поле.

Если вы про JSONB в PostgreSQL, то он автоматически индексирует по полям внутри JSON.
Это позволяет быстрее искать. Но, если поиск по отдельным полям JSON не нужен, то лишние индексы только снижают производительность и требуют места на диске.

[Дмитрий Свиридов]

FanatPHP, как бы там ни было, мой ответ полностью отвечает на поставленный вопрос: "нормальная ли это практика, стоит ли так делать и почему?".

[Дмитрий Свиридов]

stilic, насчет "автоматически" - чего-то не уверен. Спорить не буду - не знаю (вроде бы, gin-индекс для jsonb надо отдельно вручную вешать). Но в любом случае ничего не мешает использовать тип JSON вместо JSONB. Это куда правильнее, чем хранить php-сериализацию в базе.

[stilic]

Дмитрий Свиридов,
насчет "автоматически" - чего-то не уверен. Спорить не буду - не знаю (вроде бы, gin-индекс для jsonb надо отдельно вручную вешать).
https://youtu.be/zoW3lqbaGxM
Это сами создатели типа JSONB, разработчики PG и говорят.

[Дмитрий Свиридов]

stilic, ок, тогда не JSONB, а просто JSON (я изначально, кстати, про JSONB, вроде, даже и не писал).

[stilic]

Дмитрий Свиридов,

Но в любом случае ничего не мешает использовать тип JSON вместо JSONB. Это куда правильнее, чем хранить php-сериализацию в базе.

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

Если нужен доступ к отдельным полям объекта прямо из БД - то нужен JSON
Если нужен поиск по отдельным полям объекта прямо из БД - то нужен JSONB
Если ни первого ни второго не нужно - можно хранить как обычную строку.

[Дмитрий Свиридов]

stilic

Тогда будет проверяться синтаксис JSON, а это не всегда надо. Исходные данные могут не строго стандарту соответствовать - намучаетесь. Знаем, проходили.

И это хорошо, в базе надо корректные данные держать потому что. Впервые слышу, если честно, чтобы json кто-то хранил не по стандарту. По крайней мере, за 10 лет разработки с таким не сталкивался ни разу. Такой json может же даже не декодироваться нормально, если не соответствует стандарту - и как его потом использовать? В таком случае, конечно, можно строкой хранить, но, честно говоря, появление таких вещей говорит о серьезных проблемах в проекте. Наверняка можно (да и нужно) исходные данные обрабатывать и превращать в валидный нормальный json.

[stilic]

Дмитрий Свиридов,

И это хорошо, в базе надо корректные данные держать потому что.

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

[stilic]

Дмитрий Свиридов,

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

части проекта могут от вас вообще никак не зависеть.
1) они унаследованы и их никто не будет переделывать.
или
2) это вообще другая фирма, их данные, их API.

[Дмитрий Свиридов]

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

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

Answer 3

[Егор Казанцев]

Забудьте про такие вещи как eval и serialize - это источник багов, дырок и говнокода

Answer 4

[Владимир Коротенко]

Лучше сериализуйте в json https://www.php.net/manual/ru/function.json-encode.php
https://www.postgresql.org/docs/9.4/datatype-json.html

Некоторые базы данных (почти все) позволяют хранить json внутри специального типа поля и использовать их при запросах.

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

Comments

[FanatPHP]

опять наш синьор помидор в лужу дунул

[Владимир Коротенко]

FanatPHP,

Вот вам пример, обратите внимание на поля [VirusInfoEx] [varbinary](max) NULL, [UnVersionedMetaInfo] [dbo].[tCompressedBinary] NULL, [FileFormatMetaInfo] [varbinary](max) NULL,

USE [WSS_Content]
GO

/****** Object:  Table [dbo].[AllDocs]    Script Date: 11/23/2019 7:34:55 PM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[AllDocs](
	[Id] [uniqueidentifier] NOT NULL,
	[SiteId] [uniqueidentifier] NOT NULL,
	[DirName] [nvarchar](256) NOT NULL,
	[LeafName] [nvarchar](128) NOT NULL,
	[Level] [tinyint] NOT NULL,
	[ParentId] [uniqueidentifier] NOT NULL,
	[DeleteTransactionId] [varbinary](16) NOT NULL,
	[WebId] [uniqueidentifier] NOT NULL,
	[ListId] [uniqueidentifier] NULL,
	[DoclibRowId] [int] NULL,
	[Type] [tinyint] NOT NULL,
	[SortBehavior] [tinyint] NOT NULL,
	[Size] [int] NULL,
	[ETagVersion]  AS (case when [InternalVersion] IS NULL then NULL else ([InternalVersion]+[BumpVersion]*(256))/(256) end),
	[EffectiveVersion]  AS (case when [InternalVersion] IS NULL then NULL else [InternalVersion]+[BumpVersion]*(256) end),
	[InternalVersion] [int] NULL,
	[ContentVersion] [int] NOT NULL,
	[NextBSN] [bigint] NULL,
	[MetadataNextBSN] [bigint] NULL,
	[StreamSchema] [tinyint] NULL,
	[HasStream]  AS (case when [Type]=(0) AND ([DocFlags]&(256))=(256) AND [SetupPath] IS NULL OR [SetupPath] IS NOT NULL AND ([DocFlags]&(64))=(64) then (1) else (0) end),
	[BumpVersion] [tinyint] NOT NULL,
	[UIVersion] [int] NOT NULL,
	[Dirty]  AS (case when [BumpVersion]<>(0) then CONVERT([bit],(1)) else CONVERT([bit],(0)) end),
	[ListDataDirty] [bit] NOT NULL,
	[DocFlags] [int] NULL,
	[ThicketFlag] [bit] NULL,
	[CharSet] [int] NULL,
	[ProgId] [nvarchar](255) NULL,
	[TimeCreated] [datetime] NOT NULL,
	[TimeLastModified] [datetime] NOT NULL,
	[NextToLastTimeModified] [datetime] NULL,
	[MetaInfoTimeLastModified] [datetime] NULL,
	[TimeLastWritten] [datetime] NULL,
	[SetupPathVersion] [tinyint] NOT NULL,
	[SetupPath] [nvarchar](255) NULL,
	[SetupPathUser] [nvarchar](255) NULL,
	[CheckoutUserId] [int] NULL,
	[DraftOwnerId] [int] NULL,
	[CheckoutDate] [datetime] NULL,
	[CheckoutExpires] [datetime] NULL,
	[VersionCreatedSinceSTCheckout] [bit] NOT NULL,
	[LTCheckoutUserId]  AS (case when ([DocFlags]&(32))=(32) then [CheckoutUserId]  end),
	[CheckinComment] [nvarchar](1023) NULL,
	[IsCheckoutToLocal]  AS (case when ([DocFlags]&(512))=(512) then (1) else (0) end),
	[VirusVendorID] [int] NULL,
	[VirusStatus] [tinyint] NULL,
	[VirusInfo] [nvarchar](255) SPARSE  NULL,
	[VirusInfoEx] [varbinary](max) NULL,
	[MetaInfo] [dbo].[tCompressedBinary] NULL,
	[MetaInfoSize] [int] NULL,
	[MetaInfoVersion] [int] NOT NULL,
	[UnVersionedMetaInfo] [dbo].[tCompressedBinary] NULL,
	[UnVersionedMetaInfoSize] [int] NULL,
	[UnVersionedMetaInfoVersion] [int] NULL,
	[WelcomePageUrl] [nvarchar](260) NULL,
	[WelcomePageParameters] [nvarchar](max) NULL,
	[IsCurrentVersion] [bit] NOT NULL,
	[AuditFlags] [int] NULL,
	[InheritAuditFlags] [int] NULL,
	[UIVersionString]  AS ((CONVERT([nvarchar],[UIVersion]/(512))+'.')+CONVERT([nvarchar],[UIVersion]%(512))),
	[ScopeId] [uniqueidentifier] NOT NULL,
	[BuildDependencySet] [varbinary](max) NULL,
	[ParentVersion] [int] NULL,
	[ParentVersionString]  AS ((CONVERT([nvarchar],[ParentVersion]/(512))+'.')+CONVERT([nvarchar],[ParentVersion]%(512))),
	[TransformerId] [uniqueidentifier] NULL,
	[ParentLeafName] [nvarchar](128) NULL,
	[CtoOffset] [smallint] NULL,
	[Extension]  AS (case when charindex(N'.',[LeafName] collate Latin1_General_BIN)>(0) then right([LeafName],charindex(N'.',reverse([LeafName]) collate Latin1_General_BIN)-(1)) else N'' end),
	[ExtensionForFile]  AS (case when [Type]=(0) AND charindex(N'.',[LeafName] collate Latin1_General_BIN)>(0) then right([LeafName],charindex(N'.',reverse([LeafName]) collate Latin1_General_BIN)-(1)) else N'' end),
	[ItemChildCount] [int] NOT NULL,
	[FolderChildCount] [int] NOT NULL,
	[FileFormatMetaInfo] [varbinary](max) NULL,
	[FileFormatMetaInfoSize] [int] NOT NULL,
	[FFMConsistent] [bit] NULL,
	[ListSchemaVersion] [int] NULL,
	[ClientId] [varbinary](16) NULL,
 CONSTRAINT [AllDocs_ParentId] PRIMARY KEY CLUSTERED 
(
	[SiteId] ASC,
	[DeleteTransactionId] ASC,
	[ParentId] ASC,
	[Id] ASC,
	[Level] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 95) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[AllDocs] SET (LOCK_ESCALATION = DISABLE)
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((1)) FOR [Level]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT (0x) FOR [DeleteTransactionId]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((0)) FOR [SortBehavior]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((0)) FOR [ContentVersion]
GO

ALTER TABLE [dbo].[AllDocs] ADD  CONSTRAINT [DF_AllDocs_BumpVer_DefValue]  DEFAULT ((0)) FOR [BumpVersion]
GO

ALTER TABLE [dbo].[AllDocs] ADD  CONSTRAINT [DEFAULT_UIVersion]  DEFAULT ((512)) FOR [UIVersion]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((0)) FOR [ListDataDirty]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((0)) FOR [ThicketFlag]
GO

ALTER TABLE [dbo].[AllDocs] ADD  CONSTRAINT [setuppathversion_default]  DEFAULT ((15)) FOR [SetupPathVersion]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((0)) FOR [VersionCreatedSinceSTCheckout]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((1)) FOR [MetaInfoVersion]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((1)) FOR [IsCurrentVersion]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((0)) FOR [ItemChildCount]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((0)) FOR [FolderChildCount]
GO

ALTER TABLE [dbo].[AllDocs] ADD  DEFAULT ((0)) FOR [FileFormatMetaInfoSize]
GO

Answer 5

[stilic]

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

Comments

[S-a-n-d-r-0]

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

[stilic]

S-a-n-d-r-0, зависит от того зачем вам это надо.

[FanatPHP]

Внешний ключ тут не обязателен.

Ну ты же сам пишешь, связь 1 ко многим. То есть у тебя реляционные таблицы.

И с чего ты решил, что искать по полям не собираешься-то? Как раз наоборот, по полям своей таблицы ты ищешь в системной. И тут только один вариант -таблица-связка с двумя атрибутами, как ты и написал

[S-a-n-d-r-0]

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