Ответ 1
Кэш - это уникальный зверь, в зависимости от того, как вы его используете, тогда его можно охарактеризовать как базу данных без SQL, RDBMS или объектно-ориентированную базу данных. Конечно, это не все вещи для всех людей, поэтому знание того, каким образом каждому из них нужно какое-то объяснение.
Все это построено на основе предреляционного процедурного языка под названием MUMPS (ужасное маркетинговое название, которое ужасно для Googling, поэтому теперь они просто используют Кэш, который ужасен только для Googling). Этот язык включает операции по сохранению данных в качестве собственных команд, поэтому механизм персистентности можно оптимизировать, не затрагивая код приложения.
Этот язык имеет один тип коллекции, словарь ключей/значений с 0 или более отсортированными ключами и один тип данных, в котором операторы выполняют строгие вещи и другие, чтобы делать несколько вещей. Все ключи и значения являются экземплярами этого типа данных.
Это было в течение долгого времени, а приложения, написанные на протяжении всего этого времени, еще не выполнялись.
Этот язык предшествует первой СУБД, но позже разработчики добавленной RDBMS поддержки языка. Кэш компилирует SQL (статически или динамически) в более современную версию MUMPS, которая затем управляет движком хранения. Если это звучит странно, на самом деле это не так - каждая РСУБД компилирует или интерпретирует SQL в направлениях для этого механизма хранения.
Кэш превратился в объектно-ориентированный язык (как и многие другие языки со временем), что означает, что теперь есть 2 типа данных, исходный и тип объекта. Объекты не могут быть сохранены как ключи или значения на диске напрямую, но могут наследовать или применять методы сохранения.
Поэтому люди, использующие Cache, могут использовать объектно-ориентированный код, SQL или процедурный код или комбинировать их по своему усмотрению.
Каковы преимущества и недостатки?
Для пользователей, работающих с устаревшими приложениями MUMPS, у них практически нет выбора, поэтому я сосредоточусь на всех остальных.
Большой недостаток заключается в том, что он имеет небольшую долю на рынке (по сравнению с другими РСУБД, хотя вместо этого его можно сравнить с другими продуктами) и оценивается в одном и том же рабочем месте как коммерческая СУБД (хотя, вероятно, намного легче работать для индивидуальной сделки для какого-то конкретного своеобразного использования), поэтому для его покупки должна быть какая-то веская причина.
Кроме того, небольшая доля рынка означает меньший рынок для разработчиков. Кроме того, различные способы его использования означают, что не все разработчики кэша подходят для всех проектов: кто-то, кто поддерживает предыдущее приложение (от ранее организованного программирования) в течение последних 20 лет, может не очень хорошо использовать Cache для объектно-ориентированной сети приложения.
Другая проблема заключается в том, что библиотек кода практически не существует вне того, что предлагает Intersystems (поставщик), и они не могут конкурировать с чем-то вроде .NET или Java в размере.
Большим преимуществом является то, что объект Cache Script (современный язык MUMPS) намного больше, чем обычно, в базе данных. Это скорее преимущество, чем больше бизнес-логики в базе данных.
На самом деле, IMHO большинство преимуществ кеша приходят, если вы используете его для своей бизнес-логики. Сочетание базы данных и бизнес-логики намного проще, проще получить высокую производительность и не особенно приводит к долгосрочным проблемам обслуживания, когда среда так сильно его поддерживает.
Недостатком комбинирования базы данных и бизнес-логики в кэше является то, что перенос либо будет довольно сложным, и, как правило, ваша бизнес-логика написана на свободном языке, и вам не нужна лицензия любого вида для ее запуска. Здесь вы в значительной степени находитесь в одной лодке, как если бы ваша бизнес-логика находилась в TSQL, за исключением того, что еще труднее порт.
Если вы O.K. с этим, однако, многие вещи прекрасны. Нет ORM - коммерческий или ручной код. SQL скомпилирован в код, на который вы можете смотреть (он сгенерирован таким образом, что он оптимизирован для скорости чтения, а имена переменных могут быть такими же, как "T32", но они все еще доступны для чтения, если вам нужно), даже шаг за шагом или точка останова. Стоимость написания курсоров SQL очень низкая. Вы можете написать объектно-ориентированный код. Он интерпретировался, так что легче развиваться быстро. Если вы хотите скорость, вы можете отключить транзакции и пойти без SQL.
Я также нашел, что это очень легко администрировать. В большинстве моих опытов с ним нет такой вещи, как DBA - вам просто не нужен.