Как стать автором
Обновить

Комментарии 12

Query… Yahoo! Query Language (YQL).
А вообще интересная статья, спасибо.
А что со стоимостью/производительностью?
Для каждого сервиса (включая сервис структур) установлены квоты. Все что укладывается в пределах квот — бесплатно для использования. Если по каким то причинам нужно увеличить квоты, то мы можем изменить их по запросу для конкретного идентификатора приложений.

— Производительность сервиса структур тестировалась на сравнительно небольших массивах данных 10000, 50000, 100000 объектов на один тип данных. Производились тесты на постраничную выборку, постраничную выборку по критериям. Время выборки с учетом проверки идентификатора приложения, сессии пользователя, прав доступа к объектам (а для каждого объекта можно установить уникальные права доступа), и передачи данных по сети до клиента все в сумме составляло то 50 до 100 мс для 100000 разных объектов. Мы сделаем комплексный тест уже с десятками миллионов объектов по сервису структур и покажем результаты.
Очень интересно, будем ждать результатов. Особенно интресны сложные выборки с условиями, то что обычные постраничные будут хорошо работать я верю.
У меня пока интерес академический, но возможно и применим для какого-нибудь проетка.
Спасибо!
Можно ли полям присваивать свои (сложные) типы?
Хороший вопрос.

Эта возможность почти закончена. Можно использовать оператор точку для доступа к свойствам составных объектов.
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. Нельзя вставить ссылку на несуществующий объект. Нельзя удалить объект не очистив ссылки на него. В случае необходимости система может также сама очистить ссылки на объект при его удалении. Т.е. целостность данных поддерживается в полном объеме.

Для каких целей создавался «Сервис структур Hivext»?
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
структур позволяет разработчикам создавать свои приложения в стиле ООП, позволяет манипулировать и управлять типами и объектами разрабатываемых приложений

Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.
> Для каких целей создавался «Сервис структур Hivext»?
Хранение, выборка, удаление структурированных данных (с учетом композиции).

> Какую СУБД для хранения данных использует Ваш сервис?
MySQL

> На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
На достаточно большие, MySQL поддерживает портиции. Разработчикам предоставляется доступ к своей БД. Вопросы масштабирования решаются архитектурно и добавлением серверов. Думаю вам будет достаточно хранить по 100 млн. записей на таблицу? Многим этого за глаза. Понятное дело что все имеет разумные пределы.

> Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :)

Все верно поэтому он и называется Сервис Структур :)

И для начала не будем мешать все в кучу и отделим понятие ООП (Объектно ориентированное Проектирование) от ООП (Объектно ориентированного Программирования). Это не одно и тоже. Сервис предназначен для объектно ориентированного Проектирования, для закладки объектной структуры в будущее веб — приложение.

Так как сервис структур работает с базой, то логика программируется на клиенте.

По поводу абстракции — ее можно использовать с сервисом структур. Абстракция — это упрощенное описание объекта, я могу задать любую структуру, которая опишет объект так как мне нужно.

Инкапсуляция — это объединение данных и логики (про логику уже сказано выше) и предоставление интерфейса доступа. Интерфейс доступа это методы сервиса структур.

С наследованием ничего сложного нет, можно создать комплексный (сложный или составной тип данных).
Можно еще ассоциировать объекты, создавая связи один к одному, один ко многому, многое к одному, многое ко многому.
>авторы которых цена которых
поправьте пожалуйста. В двух местах так написано. пример:
Получим список книг, авторы которых цена которых Всезнайка и Незнайка. Hibertnate синтаксис следующий
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.