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