В целом всё замечательно, статья хорошая и ссылка на msdn действительно отвечает на все вопросы по ограничениям. Я недоволен тем, что большинство статей про Hekaton напоминают рекламу со звездочками на билбордах — «Небольшие квартиры всего за 2,5 миллиона», а ниже мелким шрифтом «Площадь 10 м2». Читаешь, пробуешь воспроизвести примеры — действительно работает, не наврали. А как попытаешься внедрить, понимаешь что с текущей схемой данных на production эту технологию применить нельзя. (слишком маловата квартирка в 10м2).
IDENTITY, Computed columns, constraints — для многих это базовые потребности.
Я понимаю что технология in-memory OLTP может эффективно применяться для определенного рода задач, в которых эти ограничения не являются ключевыми. К примеру staging таблицы в ETL или хранение фиксированных справочников. Именно про это и хочется прочитать, каковы реальные сценарии использования Hekaton с учетом всех его ограничений?
Лучше сначала про ограничения напишите, которые накладываются на таблицы и хранимые процедуры при работе в in-memory OLTP. На синтетических тестах прирост действительно хороший получается, но не каждую реальную таблицу и процедуру можно без изменений в in-memory загнать.
При этом, как правило, указывается общий вес блюда и общая калорийность, при этом в каждом ингредиенте индивидуальное соотношение белков, жиров и углеводов ради подсчета которых и нужно использовать подобные приложения.
Кстати идея для приложения — расчет весового соотношения ингредиентов в салате по составу, общему весу и калорийности ;)
А как это приложение решает проблему питания в кафе и ресторанах? При заказе риса с курой всё равно не ясно сколько грамм приходится на каждый ингредиент, да и количество растительного масла в порции овощного салата непонятно как измерить.
Они на полном серьезе считают что террористы собирают свои «миллионы долларов» через анонимные счета WebMoney и Яндекс.Деньги с лимитом в 15'000 рублей?
Я только на этих выходных с Laravel познакомился, так что еще не всё успел посмотреть. Confide вроде за authentication отвечает, а мне именно ACL нужно было реализовать.
Нашел в нем ссылку на Entrust, буду смотреть.
Уважаемые коллеги, поделитесь опытом. С помощью каких библиотек лучше Auth + ACL реализовать? Ох уж это разнообразие…
Clustered Index по своей сути это упорядоченная «куча» с удобным механизмом поиска по интересующему вас полю. Т.е. при создании кластеризованного индекса строки на страницах кучи сортируются и выстраиваются в нужной последовательности, а сверху появляется «шапка» b-tree. Куча превращается в отсортированную последовательность строк.
Отсюда вытекает ответ на ваш вопрос. К heap можно применить только одно правило сортировки, следовательно кластеризованный индекс может быть только один. Некластеризованные индексы содержат копию данных, и именно копия данных сортируется по новым правилам. Ну а для поддержания целостности, копия данных должна ссылаться на оригинал (на строки кластеризованного индекса).
IDENTITY, Computed columns, constraints — для многих это базовые потребности.
Я понимаю что технология in-memory OLTP может эффективно применяться для определенного рода задач, в которых эти ограничения не являются ключевыми. К примеру staging таблицы в ETL или хранение фиксированных справочников. Именно про это и хочется прочитать, каковы реальные сценарии использования Hekaton с учетом всех его ограничений?
Кстати идея для приложения — расчет весового соотношения ингредиентов в салате по составу, общему весу и калорийности ;)
Gamification? )))
Нашел в нем ссылку на Entrust, буду смотреть.
Уважаемые коллеги, поделитесь опытом. С помощью каких библиотек лучше Auth + ACL реализовать? Ох уж это разнообразие…
Судя по описаниям на Github, это очень похожие библиотеки. В чем разница между ними и почему нужно обе подключать?
Только вчера делал ACL на Lavarel, за основу брал https://medium.com/on-coding/a7f2fa1f9791. Похоже что ваше решение выглядит красивее, буду ждать вторую часть ))
Отсюда вытекает ответ на ваш вопрос. К heap можно применить только одно правило сортировки, следовательно кластеризованный индекс может быть только один. Некластеризованные индексы содержат копию данных, и именно копия данных сортируется по новым правилам. Ну а для поддержания целостности, копия данных должна ссылаться на оригинал (на строки кластеризованного индекса).