Если я правильно понял идею, то она заключается в следующем. Например, есть сущность "клиент" с полями: Название, ИНН, КПП. В классическом sql это будет 1 запись в таблице с 3 колонками (плюс четвертая - id). В Ideav это будет 3 строки в таблице с колонками: entity-key-value.
Если так, то как будет выглядеть, например, запрос вида "покажи все остатки товаров на складе в разрезе партий,по которым они пришли"? Или "дай список товаров, которые не продавались более трёх месяцев"?
Хорошо, оба с фронта одновременно начали делать бронь и у обоих это удалось. Такое возможно? Если нет, то за счёт чего, какая там механика под капотом?
Например, расскажите о реализации блокировок в Ideav. Классическая ситуация: 2 клиента одновременно видят один последнее яблоко на товарных остатках и хотят его купить. Кому из них достанется яблоко? Если только одному, то за счёт чего это будет реализовано?
Также интересно узнать, что приходит на замену сложным join'ам в аналитических отчётах.
Из того, что мне встречалось, самый удобный мостик между языком бизнеса и разработки предоставляет платформа 1С. Не все идеально, но тот подход выглядит гораздо более жизнеспособным, чем описанный в данной статье. Впрочем, ИМХО.
Возможность декомпозиции. При этом результат будет представлять единый юнит, а не россыпь разрозненных функций, гоняющих между собой набор одинаковых параметров.
Возможность применения DI фреймворков. Вот это та часть, которую как раз интересно было бы узнать в продолжении.
Зарегистрировался только сегодня, чтобы поставить плюс этой статье.
И отдельно спасибо за упоминание слова "этичность". Вижу, как в последние годы эта сущность постепенно покидает чат. Надеюсь, однажды этот тренд развернется, но сначала должна в полную силу проявиться "трагедия общин" на поле рекламы, удержания внимания за счёт манипуляций и и.д.
Если я правильно понял идею, то она заключается в следующем. Например, есть сущность "клиент" с полями: Название, ИНН, КПП. В классическом sql это будет 1 запись в таблице с 3 колонками (плюс четвертая - id). В Ideav это будет 3 строки в таблице с колонками: entity-key-value.
Если так, то как будет выглядеть, например, запрос вида "покажи все остатки товаров на складе в разрезе партий,по которым они пришли"? Или "дай список товаров, которые не продавались более трёх месяцев"?
Возможно, я просто не так понял вашу идею.
Хорошо, оба с фронта одновременно начали делать бронь и у обоих это удалось. Такое возможно? Если нет, то за счёт чего, какая там механика под капотом?
Например, расскажите о реализации блокировок в Ideav. Классическая ситуация: 2 клиента одновременно видят один последнее яблоко на товарных остатках и хотят его купить. Кому из них достанется яблоко? Если только одному, то за счёт чего это будет реализовано?
Также интересно узнать, что приходит на замену сложным join'ам в аналитических отчётах.
Из того, что мне встречалось, самый удобный мостик между языком бизнеса и разработки предоставляет платформа 1С. Не все идеально, но тот подход выглядит гораздо более жизнеспособным, чем описанный в данной статье. Впрочем, ИМХО.
У класса есть как минимум 2 преимущества:
Возможность декомпозиции. При этом результат будет представлять единый юнит, а не россыпь разрозненных функций, гоняющих между собой набор одинаковых параметров.
Возможность применения DI фреймворков. Вот это та часть, которую как раз интересно было бы узнать в продолжении.
Читаю хабр много лет.
Зарегистрировался только сегодня, чтобы поставить плюс этой статье.
И отдельно спасибо за упоминание слова "этичность". Вижу, как в последние годы эта сущность постепенно покидает чат. Надеюсь, однажды этот тренд развернется, но сначала должна в полную силу проявиться "трагедия общин" на поле рекламы, удержания внимания за счёт манипуляций и и.д.