В SAP HANA я использую для создания представлений вычислений.
Ранее я узнал, что представления вычислений (которые после компиляции представляют собой представления столбцов) должны быть предпочтительнее представлений Database-SQL-Views. Что касается CDS-Views, я не уверен, так ли это до сих пор. Особенно что касаемо производительности.
Также в чем разница между табличной функцией (которая заменила представления вычислений по сценарию) и представлениями CDS?
Хорошо, я считаю, что это вопрос, на который нужно ответить.
Когда SAP HANA была впервые разработана, она в значительной степени повторно использовала концепции и технологии из других, уже существующих продуктов SAP (TREX, P * TIME, MaxDB, Business Warehouse Accelerator).
Одним из фундаментальных элементов высокой производительности запросов был (и is) колоночное хранилище данных, которое в значительной степени пришло из продуктов TREX / BWA. Эти продукты, в свою очередь, были решениями очень специфических проблем (полнотекстовый поиск по каталогам и ускорение аналитических запросов из продукта хранилища данных SAP Business Warehouse).
В особенности вариант использования BWA отражается в просмотры столбцов SAP HANA. Из-за ограниченного варианта использования поддержки запросов SAP BW не требовалось общей поддержки SQL / реляционных запросов (например, без произвольной оптимизации цепочки соединений, без функций SQL, кроме SQL: 92 и т. Д.), Тогда как другие, довольно экзотические функции (например, «вертикальные») join "), которые могли использоваться SAP BW, были встроены в инструмент / механизм запросов (" механизм "явно был очень популярным термином среди разработчиков SAP).
После того, как HANA оказалась успешной в качестве платформы для запуска SAP BW, следующим шагом стало добавление гибкости и создание более общих платформ, таких как SAP Netweaver (программное обеспечение, на котором работают продукты бизнес-решений SAP), работающие на SAP HANA. Теперь были добавлены функции SQL, которые требовали дополнительных возможностей от оптимизатора запросов и «движков» выполнения. Оптимизация запросов должна быть гибкой и быстрой и должна обеспечивать производительность запросов, которая по-прежнему будет превосходить предложения существующих поставщиков СУБД (которые существовали уже более 40 лет). Это, безусловно, сложная проблема, и бросает она в глаза операционные аспекты разработки БД (масштабирование, развертывание решения, объединение данных и т. Д.).
Это привело к дублированию разработки различных инструментов, направленных на различные аспекты разработки БД.
Поддержка SQL и базовый оптимизатор SQL были сделаны более мощными, настолько, что (некоторые) запросы SQL могли быть такими же быстрыми или быстрее, чем моделируемые в представлениях расчета. И поскольку оба этих "интерфейса запросов" в конечном итоге должны были взаимодействовать с одними и теми же внутренними структурами данных (хранилище строк / столбцов), было желательно иметь только один оптимизатор запросов, который поддерживал бы все различные варианты использования.
Где-то поблизости HANA 1 SPS11 / 12 большинство представлений вычислений начали «разворачиваться» изнутри для передачи в общий оптимизатор (это то, о чем говорил флаг «Выполнить в SQL Engine»).
С тех пор я бы сказал, что аргумент производительности в пользу использования представлений вычислений справедлив только в очень определенных обстоятельствах.
Я упомянул частично совпадающие разработки, и CDS (базовые службы данных) - одна из них. Идея здесь сильно отличается от SQL. В то время как SQL дает вам «способ общения с базой данных», CDS хочет дать вашему приложению единое определение данных, которое используется пользовательским интерфейсом, логикой программы и хранилищем данных / выполнением запросов.
Это, вероятно, требует некоторого контекста (опять же): основной шаблон использования баз данных SQL разработчиками приложений заключается в том, что приложение написано в некоторой форме объектно-ориентированной реализации, а общение с БД остается на уровне / библиотеке сопоставления ( например, O / R-mappers). Это означает, что знания о том, что приложение о (то есть о бизнес-процессах), распределяются по приложению.
Некоторая информация об этом содержится в пользовательском интерфейсе (метки, форматирование, видимость и т. Д.), Часть ее находится в объектной модели приложения (зависимости объектов, иерархии, домены значений ...), а часть - в запросы к базе данных.
Такие разрозненные знания / определения затрудняют согласованность изменений, что, в свою очередь, замедляет процесс разработки и, в свою очередь, увеличивает время, необходимое для запуска приложения и получения положительного результата.
«Время окупаемости. " - это то, что здесь оптимизируется, поскольку это важно для компаний, обещающих" успех через инновации ".
Итак, эта вещь CDS теперь является частью моделей разработки, предложенных SAP, и почти сразу же затрагивает такие темы, как эволюция схемы и развертывание модели данных. Фактически, это не зависит от реальной платформы базы данных, как показано в CDS для различных ABAP.
Как это влияет на производительность запросов? На самом деле это не так.
Преимущество CDS состоит в том, что можно предоставить больше информации о модели данных, чем это возможно в HANA SQL.
Ассоциации и объединения с объявлением мощности (хотя теперь они и переоснащены на простой SQL) могут позволить оптимизатору использовать дополнительные оптимизации. Тем не менее, здесь используется тот же оптимизатор и те же «движки» выполнения запросов.
Таким образом, с точки зрения производительности (выполнения запроса) это не имеет большого значения, пока не требуется семантика запроса, для которой CDS не имеет синтаксиса (например, некоторые оконные функции).
Суть CDS на самом деле связана с производительностью процесса разработки приложений, и насколько хорошо это работает с тем, как вы занимаетесь разработкой, действительно зависит от того, сколько из них вы можете использовать.
Глядя на эти разные типы объектов с точки зрения «что я могу с ними делать функционально?» приведет к наблюдению «в основном то же самое». Разница заключается в том, как их можно оптимизировать (скриптовые представления calc обычно не могут быть развернуты в глобальный запрос для оптимизации) и в том, что можно делать с однажды созданным объектом.
Табличные функции позволяют очень легко повторно использовать в нескольких представлениях и запросы. Они также предоставляют возможность предоставить параметры функции (аналогично параметризованным представлениям) и, кроме того, позволяют императивное кодирование. Функционально, столовые функции - это своего рода швейцарский армейский нож; с ними можно делать почти все, и они по-прежнему могут быть частью глобальной оптимизации запросов.
Представления CDS, как упоминалось выше, не являются чем-то «особенным» с точки зрения времени выполнения запросов или оптимизации. Основная причина, по которой представления CDS являются «вещью», заключается в том, что с HANA SAP начала разрабатывать модели разработки (такие как XS, XSA, CAM), которые вращаются вокруг «виртуальных моделей данных».
Идея состоит в том, что структура таблиц очень часто остается стабильной и со временем меняется лишь незначительно.
В некотором смысле это "схема записи" приложений, которые вводят данные в таблицы.
"схема чтения" в большинстве случаев отличается от этого. Запросы повторно объединяют нормализованные данные в записи, которые приложение может отображать в объекты. Это позволяет приложениям рассматривать данные иначе, чем исходное приложение. В «виртуальных моделях данных» эти запросы превращаются в материальные артефакты разработки (представления), которые можно повторно использовать в приложении. Фактически, их можно рассматривать так, как если бы это была база данных с ее таблицами, представленная в виде, понятном для приложения.
Еще раз, если это что-то, что полезно для разработки вашего приложения, зависит от того, как выглядит разработка вашего приложения.
Можно ли использовать HANA без CDS? Безусловно, и есть много областей, в которых CDS не хватает (то есть ограниченный синтаксис и сопоставление функций с функциями HANA), но у него есть свои достоинства.
Я бы не стал менять существующие разработки, если они по-прежнему служат своей цели, но представления расчетов, безусловно, являются странным объектом разработки. Обучение людей использованию этих и SQL, скорее всего, будет слишком затратным по сравнению с простым использованием SQL.
Лично я предпочитаю разработку SQL на основе кода (доступны лучшие инструменты, упрощает сравнение с другими СУБД, не требует WEB IDE / HANA Studio).
Единственное, что не предоставляет разработка на основе SQL, - это расширенный аннотации / семантическая информация, используемые аналитическими инструментами внешнего интерфейса SAP (SAC & BO) - они действительно специфичны для CDS и информационных моделей (представления расчетов), но почти не используются другими аналитическими инструментами.
И это мое мнение.
Я бы добавил, что
Объяснение CDS Ларсом идеально. Нечего добавить.
Но представьте себе ситуацию, когда вы не можете создать табличную функцию из-за ограниченной лицензии (также известной как версия времени выполнения). Просто оставайтесь с представлениями по сценариям.
Основным преимуществом артефактов Hana перед CDS в настоящее время является возможность использовать входные параметры в сложных случаях для оптимизации ресурсов и производительности запросов - когда ваша логика передается в БД, а не в AS / app. Но многие встроенные функции SQL по-прежнему недоступны в графических представлениях (например, существует, JOIN on BETWEEN), поэтому я думаю, что через 10 лет артефакты HANA станут «очень редкими».
Так что изучите синтаксис CDS :)
Всегда приятно читать статью или pov от Ларса на любом носителе (StackOverflow, блог SAP, статья, твиттер).
Я просто хочу указать, что еще одна вещь, которую мне не хватает в сценариях SQL (SP, TF, SF), - это оптимизация соединения и распространение SQL, которые есть в информационном представлении.
Для меня это фокус на гибких моделях (помимо динамического соединения, которое актуально только для определенных сценариев), чтобы предоставить одно представление, которое будет работать в зависимости от того, какие столбцы запросит пользователь или приложение. Для использования семантики я могу просто открыть TF внутри информационного представления, чтобы добавить некоторые.
Вы можете сказать мне, что в CDS доступны оба варианта (оптимизация соединения, распространение SQL и аннотация), но для сложных или сложных сценариев (оконные функции отсутствуют в CDS), а также для разработчиков, не относящихся к SAP, это будет проще и удобнее. удобный подход для новичков
