NoSQL против реляционных СУБД в задаче Entity-Attribute-Value

Задача хранения в базах данных схемы типа Объект — Множество Атрибутов — Значения атрибутов давно стала «классической».
В рамках реляционных СУБД, простейшее решение выглядит как-то так (anti-pattern detected!):

    public class Product
    {
        public int Id { get; set; }
        public List<propertyvalue> PropertyValues { get; set; }
        public string ProductTitle { get; set; }
        public decimal ProductPrice { get; set; }
    }

    public class Property
    {
        public int Id { get; set; }
        public string Title { get; set; }
    }

    public class PropertyValue
    {
        public int Id { get; set; }
        public Property Property { get; set; }
        public string Value { get; set; }
    }

И это не учитывая потенциальной типизации значений свойств (некоторые могут быть числовыми, другие — датой/временем и т.п.) и полагаясь на ORM для генерации таблицы связи много-ко-многим (Product/PropertyValue).
Continue reading

RavenDB в «одноразовых» приложениях

На выходных попробовал RavenDB на небольшой задаче обработки массива документов. Документов было не очень много — порядка 50К, их обработка — задача разовая, но её длительность получалась однозначно порядка 10 часов, плюс всё это отлично параллелилось.
Поэтому возникла мысль загнать все эти документы в БД, чтобы без проблем сохранять промежуточные результаты и не волноваться за exception’ы, безвозвратно прерывающие обработку 10-часового процесса в самом конце :)
Raven-Embedded видился неплохим кандидатом для такого использования, поскольку позволял не париться с маппингами, быстро «установить» БД, просто добавив nuget пакет, позволял динамически добавлять в документы новые структуры данных (результаты обработок) ну и по идее должен был быстро работать :)
Что же из всего этого получилось?
Continue reading