@sergeydurov
Гуру

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

Есть
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).
Как валидировать, как удалять поля, насколько хорош поиск.

Прошу поделиться мыслями, как лучше решить задачу.
  • Вопрос задан
  • 563 просмотра
Пригласить эксперта
Ответы на вопрос 2
zoonman
@zoonman
⋆⋆⋆⋆⋆
Ваша идея динамических полей хорошо ложится в концепт 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, но я еще ни разу ее не видел в работе.
Ответ написан
leahch
@leahch
3Д специалист. Долго, Дорого, Дерьмово.
Да, возможно пришло время не только для монго, но и для hbase. Ваша задача, по идее очень хорошо ложится именно на hbase.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы