Как реализовать динамические поля и секции для таблицы?

Question

[Серегей Дуров]

Есть
table1, table2, tabl3....
в таблицы нужно добавлять динамичкеи поля

table1.name
table1.height
....
table2.name
table2.value
....

эти поля привазяны к секциям
которые тоже динамические
в итоге для table1
table1.nameпринадлежит секции Info
table1.height принадлежить секцииAdditional information

Если бы делать на postgress:
table1, table2....
вручную создавать где
table1
имеет к примеру
values = jsonb
и еще 2 таблицы
Section - где хранятся название секция для всех таблиц
и Fields- храняться все поля для таблиц с FK на TableN и на Section
Но боюсь впереться в возможности jsonb.

Возможно пришло время для монго, но нету опыта и мыслей, есть только вопросы(которые релевантны и для jsonb).
Как валидировать, как удалять поля, насколько хорош поиск.

Прошу поделиться мыслями, как лучше решить задачу.

Answer 1

[Philipp]

Ваша идея динамических полей хорошо ложится в концепт NoSQL.
MongoDB позволяет вам хранить документы в одной коллекции (таблице) в практически произвольной JSON-форме.
В MongoDB документы (записи) выглядят достаточно просто на примере каталога товаров:

[
	{
		_id: ObjectId("1"),
		"name": "Шкаф",
		"category": "Мебель",
		"price": 18000,
		"weight": 20.0,
		"details": {
			"height": 180,
			"width": 60,
			"depth": 40,
			"color": "белый"
		}
	},
	{
		_id: ObjectId("2"),
		"name": "Молоко",
		"category": "Продукты",
		"price": 100,
		"weight": 1.0,
		"details": {
			"volume": 1.0,
		}
	}
]

В MongoDB нет привычных полей и валидации структур, как в SQL. Т.е. забота о валидации данных ложится на плечи разработчика, но с другой стороны дает гигантское преимущество, т.к. оба варианта структур могут вполне себе мирно сосуществовать. Мой пример вам в помощь, когда у шкафов одна информация, а у молока другая.
С точки зрения выборок все с одной стороны намного проще, а с другой сложнее.
Например, если нет поля, запрос просто не вернет данные. Но можно добавить условие, при котором они будут возвращаться.
Самое сложное, что вызывает неприятие со стороны заядлых любителей реляционной модели - отсутствие внешних ключей и объединений (join). Тут нужно в корне пересматривать отношение к структурированию данных и про это написано много книг, статей и т.д. Вам нужно очень четко понимать, где и когда какую модель и структуру выгоднее использовать.
Например, если вам дороже гибкость и возможность быстрого масштабирования (собирать данные с тысяч разных устройств в режиме реального времени), то MongoDB, но если нужна жесткая сложная структура, например CRM с адским биллингом и злостными транзакциями, то тут надо выбирать SQL вроде PostreSQL или Oracle.

MongoDB это такой хороший стартаперский вариант, в котором структуру базы приходится менять несколько раз на день, да еще при дикой нагрузке и без даунтайма. SQL это такой плановый энтерпрайз, который будет рассылать все уведомления за месяц, потом останавливать всё, делать миграции, потом запускать, тестировать.

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

Comments

[Серегей Дуров]

Philipp спасибо за ответ, какой вариант связей в монге, вы бы предложили в моем случае? Или поделиться ссылкой?

[Philipp]

Серегей Дуров, в вашем случае может подойти embedding.

[Серегей Дуров]

Philipp, интересный момент, что мне нужно четко знать какие поля есть в каждого row таблицы. И эти поля должны быть одинаковы. А поля должны принадлежать определенным секциям.
Если использовать embedding паттерн то структура выгдлядела бы след добразом:

{
	table1 {
 		sections: [
	 		{
	 			name: 'Section1',
	 			fields: [
	 				{
	 					name: 'field1',
	 					position: 1,
	 					value: 'Test value'
	 				},
	 				{
	 					name: 'field2',
	 					position: 2,
	 					value: 'Test value2'
	 				},
	 			]
 			},
 			{
	 			name: 'Section2',
	 			fields: [
	 				{
	 					name: 'field1',
	 					position: 1,
	 					value: 'Test value'
	 				},
	 				{
	 					name: 'field2',
	 					position: 2,
	 					value: 'Test value2'
	 				},
	 			]
 			},
 		]
	}
}

И при добавлении нового field в секцию, нужно обновить все fields.
В итоге все мысли сводятся к
этому варианту

Если бы делать на postgress:
table1, table2....
вручную создавать где
table1
имеет к примеру
values = jsonb
и еще 2 таблицы
Section - где хранятся название секция для всех таблиц
и Fields- храняться все поля для таблиц с FK на TableN и на Section
Но боюсь впереться в возможности jsonb.

Но не хочется из-за не знания, превратить монгу в типичную реляционную бд

[Philipp]

Серегей Дуров, если вам нужна жесткая структура, тогда используйте PostreSQL.

Если у вас проблемы с описанием стурктур, то обратите внимание на разные ODM, например https://mongoosejs.com/docs/guide.html
Они позволяют поддерживать структуру или даже реализовывать связи через populate.

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

[Серегей Дуров]

На видео вы можете видеть:
Видео

[Серегей Дуров]

2 сущности - таблица (Utilities), и field builder - где создаются поля для этой таблицы.
мы добавили поле Dima, в секцию Utility information.

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

[Серегей Дуров]

Philipp, так звучит задача

[Philipp]

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

Answer 2

[Алексей Черемисин]

Да, возможно пришло время не только для монго, но и для hbase. Ваша задача, по идее очень хорошо ложится именно на hbase.