Ваша идея динамических полей хорошо ложится в концепт 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, но я еще ни разу ее не видел в работе.
