Недавно узнал о функциях serialize и unserialize в php. Таким способом можно записать целый массив в 1 ячейку таблицы sql, не создавая при этом дополнительной таблицы. Вопрос: нормальная ли это практика, стоит ли так делать и почему?
Это используют когда у тебя заранее не известно количество "полей" для сохранения данных, или это количество "гуляет", в зависимости от типа контента.
Ну это я так себе представляю.
Ни в коем случае.
Твоя база данных не зря названа реляционной, то есть связанной. Информация хранится в связанных между собой таблицах. Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности. Что в миллион раз важнее лени "создавать дополнительную таблицу"
И не надо слушать советчиков из соседних ответов.
Увы, поколение милленниалов не умеет воспринимать письменный текст, и реагирует в лучшем случае на пару ключевых слов в вопросе, не воспринимая корнтекст. Который, чтобы было понятно, звучит так: Нашел у папы в сарае заряженнвую двустволку. Прикладом очень удобно орехи колоть. Это удобнее потому что из щипцов орехи вываливаются. Нормально ли колоть орехи заряженным ружьем?
Сериализованные данные стоит хранить в бд только в очень крайнем случае.
На данном этапе вообще забудь про такую возможность и учись работать с БД правильно.
Не надо слушать малолетних незнаек из соседних ответов.
...
Информация хранится в связанных между собой таблицах. Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности.
именно так как вы и писали - мы и теряем производительность.
зато компенсируем это гибкостью доступа к данным - именно для этого и нужно раскладывать по таблицам.
можно вам посоветовать все же прямо вашими же словами:
Надо купить себе букварь по базам данных, прочитать его, чтобы такие глупости не приходили в голову.
Хорошо, а если у меня 5 видов пунктов меню в движке и у каждого вида свой набор настроек (полей), но в тоже время таблица Menu_items у меня одна и хранить пункты меню надо в ней.
Пример из реальности - пункты меню Joomla, там настройки как раз в одном поле params и сохраняются, в json.
Антон Р., можно вынести связанную сущность в отдельную таблицу и привязать по внешнему ключу, есть еще шаблон eav для таких случаев. Джумла плохой пример для перенятия практик
Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности. Что в миллион раз важнее лени "создавать дополнительную таблицу"
А насколько ты уверен, что получить нужные данные из таблицы, а потом декодировать значение json-филда в плане производительности хуже, чем операция join? Напомню, что данные, которые в json-поле хранят, обычно могут быть не только абсолютно разные для каждой записи, но и иметь древовидную структуру, которая у разных записей различна в плане глубины вложенности. Как ты собрался это решать дополнительными таблицами, сколько их будет и будет ли это работать быстрее?
FanatPHP , почитали одну книжку по теории РСУБД и раздаете советы одновременно глупые и категоричные.
База данных предназначена для решения бизнес задач. Нормализованная база данных в общем случае жуткий монстр. Так что в некоторых случаях лучше хранить метаданные в json. Типичный пример это слаботипизированные структуры, типа настроек плагина или метаданных документа.
Нормализованная база данных в общем случае жуткий монстр
как вы поддерживаете целостность таких данных? Ну напихали в одно поле все настройки, пришли еще 10 разработчиков допиливать этот участок кода, как вы им сообщаете о критических параметрах без которых нельзя обойтись? На уровне кода проверяете наличие каждого поля из бд?
Barmunk, Все зависит от приложения. В общем случае я вообще стараюсь не хранить что то в БД.
Точнее даже не так. Есть базовый набор параметров, которые доступны в БД, все остальное взаимодействие происходит выше уровнем, DB layer или BL layer.
И ручками в sql вообще не лезть.
Но вы видимо спрашиваете про транзакции между 2 строками? Грубо говоря перевод с одного счета на другой?
Barmunk, а разве в случае "один ко многим" целостность как-то гарантируется в такой ситуации? Ничего не мешает в таблице с параметрами указать не все. Уровень вложенности более одного так тоже хранить особо не получится.
Да и при этом как использовать нормально limit и offset, если мне нужно получить список сущностей с их параметрами? Можно, конечно, делать 2 запроса: первый к таблице сущностей (с лимитом и оффсетом), потом взять их id и вторым запросом к базе через IN (список id сущностей) вытащить и их параметры, после чего на уровне кода все связать - но так ли уж это удобно? И как быть, если вложенность большая?
Если уж и требуется такие структуры хранить, то лучше, как уже написали, хранить в json. Во-первых, у mysql и postgresql для таких данных есть специальное поле. Во-вторых, serialize - это пхпшная штука, поэтому если с базой будет взаимодействовать другой сервис, написанный не на php, будут заморочки и велосипеды.
Во-первых, у mysql и postgresql для таких данных есть специальное поле.
Если вы про JSONB в PostgreSQL, то он автоматически индексирует по полям внутри JSON.
Это позволяет быстрее искать. Но, если поиск по отдельным полям JSON не нужен, то лишние индексы только снижают производительность и требуют места на диске.
stilic, насчет "автоматически" - чего-то не уверен. Спорить не буду - не знаю (вроде бы, gin-индекс для jsonb надо отдельно вручную вешать). Но в любом случае ничего не мешает использовать тип JSON вместо JSONB. Это куда правильнее, чем хранить php-сериализацию в базе.
Дмитрий Свиридов,
насчет "автоматически" - чего-то не уверен. Спорить не буду - не знаю (вроде бы, gin-индекс для jsonb надо отдельно вручную вешать). https://youtu.be/zoW3lqbaGxM
Это сами создатели типа JSONB, разработчики PG и говорят.
Но в любом случае ничего не мешает использовать тип JSON вместо JSONB. Это куда правильнее, чем хранить php-сериализацию в базе.
Тогда будет проверяться синтаксис JSON, а это не всегда надо. Исходные данные могут не строго стандарту соответствовать - намучаетесь. Знаем, проходили.
Нужно понимать что и почему и когда использовать, а когда - не надо.
Если нужен доступ к отдельным полям объекта прямо из БД - то нужен JSON
Если нужен поиск по отдельным полям объекта прямо из БД - то нужен JSONB
Если ни первого ни второго не нужно - можно хранить как обычную строку.
Тогда будет проверяться синтаксис JSON, а это не всегда надо. Исходные данные могут не строго стандарту соответствовать - намучаетесь. Знаем, проходили.
И это хорошо, в базе надо корректные данные держать потому что. Впервые слышу, если честно, чтобы json кто-то хранил не по стандарту. По крайней мере, за 10 лет разработки с таким не сталкивался ни разу. Такой json может же даже не декодироваться нормально, если не соответствует стандарту - и как его потом использовать? В таком случае, конечно, можно строкой хранить, но, честно говоря, появление таких вещей говорит о серьезных проблемах в проекте. Наверняка можно (да и нужно) исходные данные обрабатывать и превращать в валидный нормальный json.
В таком случае, конечно, можно строкой хранить, но, честно говоря, появление таких вещей говорит о серьезных проблемах в проекте
части проекта могут от вас вообще никак не зависеть.
1) они унаследованы и их никто не будет переделывать.
или
2) это вообще другая фирма, их данные, их API.
stilic, да нет, совершенно нормальная практика решать, как обрабатывать данные и в каком виде хранить в своей же базе данных. Данные приходят в ваш сервис, ваш же сервис их пишет в вашу же базу. Вполне логично их как-либо обрабатывать для дальнейшего использования. Так можно и внешние ключи в базе не использовать - какая разница, какой id туда будут вписывать.
В общем, не вижу смысла спорить особо. Все равно каждый из нас останется при своем мнении, как я понимаю. Главное, что хранить данные в json, а не в php-шной сериализации. Вопрос изначально в этом ведь и заключался.
Вот вам пример, обратите внимание на поля [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
Не собираюсь искать по полям и не нужен контроль целостности. К существующему проекту добавлял свою таблицу. И появилась необходимость связать ее с уже существующей системной таблицей связью 1 ко многим (1 у моей таблицы, многим - у системной). Но просто взять и добавить внешний ключ в системную таблицу нельзя. Остался выбор: записать массив первичных ключей в отдельный атрибут своей таблицы или создать отдельную таблицу всего с 2мя атрибутами.
Вот и задумался, как лучше поступить в такой ситуации?
Ну ты же сам пишешь, связь 1 ко многим. То есть у тебя реляционные таблицы.
И с чего ты решил, что искать по полям не собираешься-то? Как раз наоборот, по полям своей таблицы ты ищешь в системной. И тут только один вариант -таблица-связка с двумя атрибутами, как ты и написал
FanatPHP, Не собирался искать по полям, потому что это должен отдельно делать системный компонент. Но думаю, ты прав. Если эта всратая логика когда-то будет переписана нормально, то возникнет необходимость что-то искать по этим полям своей таблицы. И лучше предусмотреть такой сценарий заранее
