Comments 12
Query… Yahoo! Query Language (YQL).
А вообще интересная статья, спасибо.
А что со стоимостью/производительностью?
А что со стоимостью/производительностью?
Для каждого сервиса (включая сервис структур) установлены квоты. Все что укладывается в пределах квот — бесплатно для использования. Если по каким то причинам нужно увеличить квоты, то мы можем изменить их по запросу для конкретного идентификатора приложений.
— Производительность сервиса структур тестировалась на сравнительно небольших массивах данных 10000, 50000, 100000 объектов на один тип данных. Производились тесты на постраничную выборку, постраничную выборку по критериям. Время выборки с учетом проверки идентификатора приложения, сессии пользователя, прав доступа к объектам (а для каждого объекта можно установить уникальные права доступа), и передачи данных по сети до клиента все в сумме составляло то 50 до 100 мс для 100000 разных объектов. Мы сделаем комплексный тест уже с десятками миллионов объектов по сервису структур и покажем результаты.
— Производительность сервиса структур тестировалась на сравнительно небольших массивах данных 10000, 50000, 100000 объектов на один тип данных. Производились тесты на постраничную выборку, постраничную выборку по критериям. Время выборки с учетом проверки идентификатора приложения, сессии пользователя, прав доступа к объектам (а для каждого объекта можно установить уникальные права доступа), и передачи данных по сети до клиента все в сумме составляло то 50 до 100 мс для 100000 разных объектов. Мы сделаем комплексный тест уже с десятками миллионов объектов по сервису структур и покажем результаты.
Можно ли полям присваивать свои (сложные) типы?
Хороший вопрос.
Эта возможность почти закончена. Можно использовать оператор точку для доступа к свойствам составных объектов.
GetProperty(appid, session, «MyComplexType», «propA.propB»);
или использовать при запросе в критериях
GetObjectsByCriteria(appid, session, «MyComplexType», «propA.propB = 100», form, count);
Эта возможность почти закончена. Можно использовать оператор точку для доступа к свойствам составных объектов.
GetProperty(appid, session, «MyComplexType», «propA.propB»);
или использовать при запросе в критериях
GetObjectsByCriteria(appid, session, «MyComplexType», «propA.propB = 100», form, count);
да можно. можно создавать свои простые типы на базе стандартных системных типов, потом создавать типы с полями ранее созданных разработчиком типов. получается ссылочная архитектура. и как сказано выше можно использовать в критериях поиска правила фильтрации по вложенным типам.
А что используется в качестве значений для таких полей? Айдишники? Поддерживается ли целостность данных на уровне БД (внешние ключи и все такое)?
смотря для чего. мы стараемся сделать максимально удобно и интуитивно понятно. к примеру
DefineType(appid, session, «author», {firstname:«string», lastname:«string»})
DefineType(appid, session, «book», {price:«float», name:«string», description:«string(500)», author:" author"})
тут мы создали тип author и тип book который содержит поле автор с ранее определенным типом author
далее создадим объект author
CreateObject(appid, session, «author», {firstname:«Yasya», lastname:«Pupkin»}) ---> id = 1
его ИД = 1
создадим объект book
CreateObject(appid, session, «book», {price:10.5, name:«Разработка веб-приложений», description:«о проектирование...», author:1})
как видно мы ссылаемся на объект типа author с ИД = 1
а можно и так
CreateObject(appid, session, «book», {price:10.5, name:«Разработка веб-приложений», description:«о проектирование...», author:"{firstname:«Ivan», lastname:«Petrov»}})
тогда сперва создастся объект author, а потом создастся объект book c привязкой к только что созданному объекту author
Связка объектов производится по первичным ключам, у нас это ИД объектов. С вопросами сохранения целостности данных отлично справляется Hibernate. Нельзя вставить ссылку на несуществующий объект. Нельзя удалить объект не очистив ссылки на него. В случае необходимости система может также сама очистить ссылки на объект при его удалении. Т.е. целостность данных поддерживается в полном объеме.
DefineType(appid, session, «author», {firstname:«string», lastname:«string»})
DefineType(appid, session, «book», {price:«float», name:«string», description:«string(500)», author:" author"})
тут мы создали тип author и тип book который содержит поле автор с ранее определенным типом author
далее создадим объект author
CreateObject(appid, session, «author», {firstname:«Yasya», lastname:«Pupkin»}) ---> id = 1
его ИД = 1
создадим объект book
CreateObject(appid, session, «book», {price:10.5, name:«Разработка веб-приложений», description:«о проектирование...», author:1})
как видно мы ссылаемся на объект типа author с ИД = 1
а можно и так
CreateObject(appid, session, «book», {price:10.5, name:«Разработка веб-приложений», description:«о проектирование...», author:"{firstname:«Ivan», lastname:«Petrov»}})
тогда сперва создастся объект author, а потом создастся объект book c привязкой к только что созданному объекту author
Связка объектов производится по первичным ключам, у нас это ИД объектов. С вопросами сохранения целостности данных отлично справляется Hibernate. Нельзя вставить ссылку на несуществующий объект. Нельзя удалить объект не очистив ссылки на него. В случае необходимости система может также сама очистить ссылки на объект при его удалении. Т.е. целостность данных поддерживается в полном объеме.
Для каких целей создавался «Сервис структур Hivext»?
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
структур позволяет разработчикам создавать свои приложения в стиле ООП, позволяет манипулировать и управлять типами и объектами разрабатываемых приложений
Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.
> Для каких целей создавался «Сервис структур Hivext»?
Хранение, выборка, удаление структурированных данных (с учетом композиции).
> Какую СУБД для хранения данных использует Ваш сервис?
MySQL
> На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
На достаточно большие, MySQL поддерживает портиции. Разработчикам предоставляется доступ к своей БД. Вопросы масштабирования решаются архитектурно и добавлением серверов. Думаю вам будет достаточно хранить по 100 млн. записей на таблицу? Многим этого за глаза. Понятное дело что все имеет разумные пределы.
> Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :)
Все верно поэтому он и называется Сервис Структур :)
И для начала не будем мешать все в кучу и отделим понятие ООП (Объектно ориентированное Проектирование) от ООП (Объектно ориентированного Программирования). Это не одно и тоже. Сервис предназначен для объектно ориентированного Проектирования, для закладки объектной структуры в будущее веб — приложение.
Так как сервис структур работает с базой, то логика программируется на клиенте.
По поводу абстракции — ее можно использовать с сервисом структур. Абстракция — это упрощенное описание объекта, я могу задать любую структуру, которая опишет объект так как мне нужно.
Инкапсуляция — это объединение данных и логики (про логику уже сказано выше) и предоставление интерфейса доступа. Интерфейс доступа это методы сервиса структур.
С наследованием ничего сложного нет, можно создать комплексный (сложный или составной тип данных).
Можно еще ассоциировать объекты, создавая связи один к одному, один ко многому, многое к одному, многое ко многому.
Хранение, выборка, удаление структурированных данных (с учетом композиции).
> Какую СУБД для хранения данных использует Ваш сервис?
MySQL
> На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
На достаточно большие, MySQL поддерживает портиции. Разработчикам предоставляется доступ к своей БД. Вопросы масштабирования решаются архитектурно и добавлением серверов. Думаю вам будет достаточно хранить по 100 млн. записей на таблицу? Многим этого за глаза. Понятное дело что все имеет разумные пределы.
> Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :)
Все верно поэтому он и называется Сервис Структур :)
И для начала не будем мешать все в кучу и отделим понятие ООП (Объектно ориентированное Проектирование) от ООП (Объектно ориентированного Программирования). Это не одно и тоже. Сервис предназначен для объектно ориентированного Проектирования, для закладки объектной структуры в будущее веб — приложение.
Так как сервис структур работает с базой, то логика программируется на клиенте.
По поводу абстракции — ее можно использовать с сервисом структур. Абстракция — это упрощенное описание объекта, я могу задать любую структуру, которая опишет объект так как мне нужно.
Инкапсуляция — это объединение данных и логики (про логику уже сказано выше) и предоставление интерфейса доступа. Интерфейс доступа это методы сервиса структур.
С наследованием ничего сложного нет, можно создать комплексный (сложный или составной тип данных).
Можно еще ассоциировать объекты, создавая связи один к одному, один ко многому, многое к одному, многое ко многому.
>авторы которых цена которых
поправьте пожалуйста. В двух местах так написано. пример:
Получим список книг, авторы которых цена которых Всезнайка и Незнайка. Hibertnate синтаксис следующий
поправьте пожалуйста. В двух местах так написано. пример:
Получим список книг, авторы которых цена которых Всезнайка и Незнайка. Hibertnate синтаксис следующий
Sign up to leave a comment.
Онлайн База Данных, сервис структур данных, динамическая объектно-реляционная проекция (Dynamic ORM)