Вграждането на структура от данни в поле може да работи за прости случаи, но ви пречи да се възползвате от релационни бази данни. Релационните бази данни са предназначени да намират, актуализират, изтриват и защитават вашите данни. С вградено поле, съдържащо собствени wad-o-данни (масив, JSON, xml и т.н.), вие сами ще напишете целия код, за да направите това.
Има случаи, в които вграденото поле може да е по-подходящо, но за този въпрос като пример ще използвам случай, който подчертава предимствата на подхода за свързана таблица.
Представете си пример за потребител и публикация за блог.
За вградено решение за публикуване ще имате таблица нещо подобно (psuedocode - те вероятно не са валидни ddl):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Със свързани таблици бихте направили нещо като
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Инструменти за обектно релационно съпоставяне (ORM) :С вградената публикация вие ще пишете кода ръчно, за да добавяте публикации към потребител, да навигирате през съществуващи публикации, да ги валидирате, изтривате и т.н. С дизайна на отделната таблица можете да използвате ActiveRecord (или каквато и да е обектно-релационна система, която искате използват) инструменти за това, които трябва да опростят кода ви.
Гъвкавост :Представете си, че искате да добавите поле за дата към публикацията. Можете да го направите с вградено поле, но ще трябва да напишете код, за да анализирате вашия масив, да потвърдите полетата, да актуализирате съществуващите вградени публикации и т.н. С отделната таблица това е много по-лесно. В допълнение, да приемем, че искате да добавите редактор към вашата система, който одобрява всички публикации. С релационния пример това е лесно. Като пример, за да намерите всички публикации, редактирани от „Боб“ с ActiveRecord, трябва само:
Editor.where(name: 'Bob').posts
За вградената страна ще трябва да напишете код, за да преминете през всеки потребител в базата данни, да анализирате всеки един от техните публикации и да потърсите „Боб“ в полето за редактор.
Ефективност :Представете си, че имате 10 000 потребители със средно по 100 публикации всеки. Сега искате да намерите всички публикации, направени на определена дата. С вграденото поле трябва да преминете през всеки запис, да анализирате целия масив от всички публикации, да извлечете датите и да проверите тази, която искате. Това ще сдъвче процесора и диска i/0. За базата данни можете лесно да индексирате полето за дата и да извадите точните записи, от които се нуждаете, без да анализирате всеки пост от всеки потребител.
Стандарти :Използването на структура от данни, специфична за доставчика, означава, че преместването на вашето приложение в друга база данни може да бъде трудно. Изглежда, че Postgres има богат набор от типове данни, но те не са същите като MySQL, Oracle, SQL Server и т.н. Ако се придържате към стандартните типове данни, ще ви е много по-лесно да сменяте бекенда.
Това са основните проблеми, които виждам отгоре. Направих тази грешка и платих цената за нея, така че освен ако няма супер убедителна причина, направете друго, бих използвал отделната таблица.
