Здравствуйте, Borisman2, Вы писали: B>Сразу оговорюсь, сейчас я зол, раздражен и раздосадован. Поэтому могу немного того... необъективно выражаться.
Ок, не проблема B>Столь же эффективный ассоциативный доступ предполагает соотвтетствие "ключ"->"объект",
Гм. Вообще-то под ассоциативным доступом понимают несколько более широкое понятие. Ассоциативный доступ — это доступ на основе свойств объекта, а не его identity. Именно поддержка ассоциативного доступа сделала РСУБД такими популярными. Ты пользуешься ассоциативным доступом почти всякий раз, как выполняешь запрос по неуникальным атрибутам:
select * from Employee where salary > 500
B>что приводит нас ко всем известным РСУБД как это не печально.
Этого я не понял. Да, в РСУБД ассоциативный доступ реализован. И круто то, что он реализован эффективно: современный оптимизатор запросов учитывает столько деталей, что редкий DBA способен увеличить производительность (без пересмотра схемы данных). Но почему так печально? Я-то и спрашиваю "а если этот доступ будет реализован естественным образом?" B>Т.е. в принципе, конечно, можно сделать такую фичу. И будет работать, и хорошо будет работать (может быть).
Ну, вот я как бы не вижу непреодолимых проблем сделать эту фичу Преодолимые есть — пытаюсь преодолеть. B>И так и делают обычно, как я понял...
Ну, я что-то не встречал полноценного движка запросов в полноценной объектной среде. Самый полноценный — Gemstone, но и он сильно ограничен. B>Но зачем ??? Зачем вообще тогда объекты и сложная навигация между ними ?
Ну, мне лично кажется, что сложные взаимосвязи объектам нужны для того, чтобы обеспечивать сложное поведение. ООП предлагает достаточно продвинутые средства декомпозиции (уж по крайней мере более продвинутые, чем SQL-ориентированные СУБД). B>Кто будет создавать ключи ? Если ООБД, то ключи будут иметь неудобоваримый вид (как, например, OID). Если пользователь, то какая же это ООБД ? B>Или я чересчур драматизирую ?
По-моему, я невнятно выразился. Что ты называешь ключами? Я имею в виду банальную поддержку запросов вида
Это близкий к реальному код на C# 2.0. При этом независимо от количества реализаций интерфейса IEmployee результирующая коллекция будет содержать все удовлетворяющие условию объекты.
При этом по полям реальных классов можно будет строить индексы, которые будут автоматически использоваться движком так же, как это происходит в RDBMS. B>А в общем говоря, проблема ведь не в ключах, а в том, что диаграммами классов по факту очень трудно описывать предметную область.
Ну вот это уже другой вопрос. B>Слишком уж строгие ограничения налагает иерархия классов на объекты. В реальном мире все может быть гораздо гибче.
B>Насчет навигационной сущности ООП, как правильно заметил этот (собака!) B. Jacobs здесь : http://www.geocities.com/tablizer/core1.htm
Я вроде понял рассуждения собаки Якобса. Я пытаюсь понять — что будет, если мы реализуем альтернативу навигационному доступу?
Здравствуйте, Sinclair, Вы писали:
S>Я вроде понял рассуждения собаки Якобса. Я пытаюсь понять — что будет, если мы реализуем альтернативу навигационному доступу?
В общем, не получится альтернативы НАВИГАЦИОННОМУ доступу, по той простой причине, что связи между объектами в ООП скрыты инкапсуляцией. Можно, конечно, пытаться смотреть ВНУТРЬ объекта минуя инкапсуляцию, но это нарушение идеологии ООП. Таким образом, любой доступ к ОО модели по сути навигационный. XPATH тому подтверждение.
S>Ну, мне лично кажется, что сложные взаимосвязи объектам нужны для того, чтобы обеспечивать сложное поведение. ООП предлагает достаточно продвинутые средства декомпозиции (уж по крайней мере более продвинутые, чем SQL-ориентированные СУБД).
Какие такие средства ??? Иерархии классов что-ли ? Я тоже так думал. Раньше.
S>По-моему, я невнятно выразился. Что ты называешь ключами? Я имею в виду банальную поддержку запросов вида...
Сорри, айдентити тут и в самом деле не при чем
B>А в общем говоря, проблема ведь не в ключах, а в том, что диаграммами классов по факту очень трудно описывать предметную область. S>Ну вот это уже другой вопрос.
Самый страшный вопрос, как это не печально. Никогда, похоже, ООБД не сравнятся с РСУБД в способности гибко описывать данные реального мира (например, в бизнес-приложениях)
Здравствуйте, Borisman2, Вы писали:
B>В общем, не получится альтернативы НАВИГАЦИОННОМУ доступу, по той простой причине, что связи между объектами в ООП скрыты инкапсуляцией. Можно, конечно, пытаться смотреть ВНУТРЬ объекта минуя инкапсуляцию, но это нарушение идеологии ООП. Таким образом, любой доступ к ОО модели по сути навигационный. XPATH тому подтверждение.
Ну ё-моё! Я не спрашиваю "получится или не получится"! Я спрашиваю: "Что будет, когда получится?" Я привел тебе пример запроса, который безо всякого нарушения инкапсуляции выполняет ассоциативный доступ.
S>>Ну, мне лично кажется, что сложные взаимосвязи объектам нужны для того, чтобы обеспечивать сложное поведение. ООП предлагает достаточно продвинутые средства декомпозиции (уж по крайней мере более продвинутые, чем SQL-ориентированные СУБД). B>Какие такие средства ??? Иерархии классов что-ли ? Я тоже так думал. Раньше.
Ну почему. Интерфейсы, иерархии классов, иерархии объектов, делегирование и агрегация. Обрати внимание, что практически никакие современные приложения не строятся на базе голой СУБД. Тут же возникает какой-то прикладной слой.
S>>По-моему, я невнятно выразился. Что ты называешь ключами? Я имею в виду банальную поддержку запросов вида... B>Сорри, айдентити тут и в самом деле не при чем
Я согласен. Так вот ты можешь прокомментировать влияние поддержки вот таких запросов? (я в курсе, что пока никто их не поддерживает. Это ненадолго.) B>Самый страшный вопрос, как это не печально. Никогда, похоже, ООБД не сравнятся с РСУБД в способности гибко описывать данные реального мира (например, в бизнес-приложениях)
Вот это очень странно. А что такого есть в РСУБД, чего нет в ООП? На мой взгляд, полноценная ООСУБД должна сводиться к РСУБД в частном случае отказа от наследования, инкапсуляции и полиморфизма. В Java это невозможно, но возможно в С++ и .Net. Берем произвольную реляционную модель, "гибко описывающую данные реального мира". А теперь заменяем все таблички на struct-ы, а форейн кеи на указатели. Ну ладно, триггеры есть — нет проблем, заворачиваем поля в свойства, код триггера пишем в сеттер. С какого момента появляется негибкость?
Если ты имеешь в виду какую-то конкретную ООСУБД — то не трать порох, я и так знаю, что они отстой
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Borisman2, Вы писали: S>Ну ё-моё! Я не спрашиваю "получится или не получится"! Я спрашиваю: "Что будет, когда получится?" Я привел тебе пример запроса, который безо всякого нарушения инкапсуляции выполняет ассоциативный доступ.
Честно говоря, трудно ответить, мозгов не хватает. Н опопробую.
Вот более конкретно
class Emplyee
{
private float salary;
public float getSalary(){...}
}
class Department
{
private std::vector<Employee> employees;
public std::vector<Employee> getEmployees();
}
class Region
{
private std::vector<Department> depts;
public std::vector<Department> getDepts();
}
В этом случае 2 есть вараинта запросов.
1) Навигационный XPATH запрос
не буджу приводить код, сложно слишком. Недостатки понятны я думаю.
Но проблема в том, что экстентные запросы тоже нарушают инкапсуляцию! Что если клиенту НЕЛЬЗЯ знать о работниках какого-то определенного департамента ??? Как это реализовать???
В общем, имхо, такие запросы выродятся в некое подобие реляционных и весь "смак" ООП будет потерян.
S>Ну почему. Интерфейсы, иерархии классов, иерархии объектов, делегирование и агрегация. Обрати внимание, что практически никакие современные приложения не строятся на базе голой СУБД. Тут же возникает какой-то прикладной слой.
Иерархии классов слишком жестки. Иерархии обектов — по сути отношения между объектами, т.е. реляционная теория. Интерфейсы также вещь настолько жесткая, что применить к реальному миру сложновато.
S>Я согласен. Так вот ты можешь прокомментировать влияние поддержки вот таких запросов? (я в курсе, что пока никто их не поддерживает. Это ненадолго.)
Такие запросы (кажется) превратят ООБД в РСУБД с потерей всякого смысла.
S>Вот это очень странно. А что такого есть в РСУБД, чего нет в ООП? На мой взгляд, полноценная ООСУБД должна сводиться к РСУБД в частном случае отказа от наследования, инкапсуляции и полиморфизма.
Да, это все верно, однако зачем огород городить, если мы хотим реляционных отнощений ??? Ну давайте откажемся от иерархий классов вообще....Будет класс — таблица м колонками и строками... Все довольны Написали ООБД.
S>Если ты имеешь в виду какую-то конкретную ООСУБД — то не трать порох, я и так знаю, что они отстой
Нет, не имею. Вернее имею (свою родную самодельную на Питоне) но не введу
Здравствуйте, Borisman2, Вы писали:
B>Но проблема в том, что экстентные запросы тоже нарушают инкапсуляцию! Что если клиенту НЕЛЬЗЯ знать о работниках какого-то определенного департамента ??? Как это реализовать???
ну если уже даже сейчас это можно реализовать на уровне SQL-сервера, то, думаю, в свежесозданной ООБД никакой проблемы не составит...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, Borisman2, Вы писали:
B>Вот более конкретно B>
B>class Emplyee
B>{
B> private float salary;
B> public float getSalary(){...}
B>}
B>class Department
B>{
B> private std::vector<Employee> employees;
B> public std::vector<Employee> getEmployees();
B>}
B>class Region
B>{
B> private std::vector<Department> depts;
B> public std::vector<Department> getDepts();
B>}
B>
B>Но проблема в том, что экстентные запросы тоже нарушают инкапсуляцию! Что если клиенту НЕЛЬЗЯ знать о работниках какого-то определенного департамента ???
Так, стоп! По-моему, мы как-то по-разному трактуем термин "инкапсуляция". Мое понимание этого термина не имеет никакого отношения к ограничению на предоставление какой-то информации какому-то определенному клиенту. Это уже называется "безопасность", и я о ней могу с удовольствием поговорить, но пока, имхо, рано.
С моей точки зрения инкапсуляция занимется сокрытием реализации, а не сокрытием информации, т.е. она означает всего лишь возможность написать вот так:
public IEnumerable<Employee> GetHighPayedEmployees()
{
return Extent<Employee>.Select(delegate(Employee self)
{
return (self.salary>500); // !!! приватное поле -> компайл-тайм еррор.
});
}
Благодаря этому мы можем подменять реализацию getSalary(), не разрушая наш запрос (и еще 200 запросов подобного рода, раскиданных по нашему ветвистому приложению). B>Как это реализовать???
Ну, вообще безопасность — тема очень широкая. Вкратце моя идея такова: с каждым объектом ассоциируется предикат безопасности. Это такая булевая функция, которая получает ссылку на аккаунт (субъект) и на объект. Этот предикат а) проверяется при выполнении операции дереференсинга и б) принудительно приделывается к каждому предикату при выполнении ассоциативного запроса. Т.е. на самом деле выполняется примерно такой запрос:
Методика "привязки" конкретной реализации AccessAllowed может быть произвольной. Мы можем:
а) фиксировать реализацию в пределах всей системы, приклеив ACL ко всем объектам. Подобие NTFS (Все типы — воображаемые):
б) Сделать его виртуальным методом объекта, разрешив, таким образом, перегрузку на уровне класса:
public class Employee
{
public override bool AccessAllowed(IPrincipal principal) // внимание! дефолтная реализация returns true!!!
{
if(principal.getOwner() is Manager)
{
return ((Manager).principal.getOwner()).controlledDepartment == this.getDepartment(); //манагеры видят только своих субординатов
}
return principal.getOwner() == this; // любой видит себя
}
}
в) "приклеивать" реализации этого метода "снаружи", при помощи атрибутов или рантайм-конфигурации, на основе произвольных критериев. Ну типа там "Все реализации ISupportsACL проверяются при помощи VerifyAclAccess(); Все потомки Document проверяются при помощи ValidateDepartmentAccess() и т.д.
В общем, я не вижу проблемы с реализацией этой фишки в ООП. Более того, она гибче и удобнее, чем аналог в RDBMS
. B>В общем, имхо, такие запросы выродятся в некое подобие реляционных и весь "смак" ООП будет потерян. B>Иерархии классов слишком жестки. Иерархии обектов — по сути отношения между объектами, т.е. реляционная теория.
Ну да, вот только реляционная теория не умеет инкапсуляции, наследования, и полиморфизма. B>Интерфейсы также вещь настолько жесткая, что применить к реальному миру сложновато.
Хм. А в чем, собсно, проблема с интерфейсами. B>Такие запросы (кажется) превратят ООБД в РСУБД с потерей всякого смысла.
А можно развернуть это утверждение? Что значит "превратят ООБД в РСУБД"? Каких именно возможностей такие запросы лишат ООБД? B>Да, это все верно, однако зачем огород городить, если мы хотим реляционных отнощений ???
Еще раз: я не спрашиваю, зачем огород городить. Ты утверждаешь, что ООБД менее гибки, чем РСУБД. Я не могу понять, почему предоставление больших возможностей уменьшает гибкость. Я не предлагаю отказываться от иерархий классов. Я говорю — если вам не нужны иерархии, то вы получаете таблицы бесплатно в виде структур. Нужны иерархии — делайте иерархии. B>Нет, не имею. Вернее имею (свою родную самодельную на Питоне) но не введу
Ок, тогда продолжаем пинать шкуру неубитого медведя, то бишь опсуждать теоретические основы ООСУБД
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Так, стоп! По-моему, мы как-то по-разному трактуем термин "инкапсуляция". Мое понимание этого термина не имеет никакого отношения к ограничению на предоставление какой-то информации какому-то определенному клиенту. Это уже называется "безопасность", и я о ней могу с удовольствием поговорить, но пока, имхо, рано.
Да, точно. Вы меня убедили. Пока что. Буду думать немного.
S>Ну да, вот только реляционная теория не умеет инкапсуляции, наследования, и полиморфизма.
А нужны ли они в базе данных? Ладно, слишком длинный вопрос...
S>Хм. А в чем, собсно, проблема с интерфейсами.
При разработке, скажем, приложений бух. учета они слишком быстро и непредсказуемо могут меняться. К тому же имеют неприятную особенность толстеть.
B>>Такие запросы (кажется) превратят ООБД в РСУБД с потерей всякого смысла. S>А можно развернуть это утверждение? Что значит "превратят ООБД в РСУБД"? Каких именно возможностей такие запросы лишат ООБД?
Ок, беру пока свои слова обратно. Не могу хорошо аргументировать, когда смогу вернемся к этому вопросу.
B>>Да, это все верно, однако зачем огород городить, если мы хотим реляционных отнощений ??? S>Еще раз: я не спрашиваю, зачем огород городить. Ты утверждаешь, что ООБД менее гибки, чем РСУБД. Я не могу понять, почему предоставление больших возможностей уменьшает гибкость.
Потому что больше — не всегда лучше. За широкие возможности придется платить, по крайней мере — простотой.
B>>Нет, не имею. Вернее имею (свою родную самодельную на Питоне) но не введу S>Ок, тогда продолжаем пинать шкуру неубитого медведя, то бишь опсуждать теоретические основы ООСУБД
Нет, нет, я не пытаюсь осуждать ООБД на основе своей реализации. Лишь говорю, что пробовал, база получилась, применить реально — не вышло пока по таким-то и таким-то причинам.
И вообще, меня больше интересовали ГРАНИЦЫ ПРИМЕНИМОСТИ ПАРАДИГМ ПРОГРАММИРОВАНИЯ, ООБД тут лишь постольку поскольку.
Здравствуйте, Borisman2, Вы писали: B>>>Нет, не имею. Вернее имею (свою родную самодельную на Питоне) но не введу S>>Ок, тогда продолжаем пинать шкуру неубитого медведя, то бишь опсуждать теоретические основы ООСУБД B>Нет, нет, я не пытаюсь осуждать ООБД на основе своей реализации. Лишь говорю, что пробовал, база получилась, применить реально — не вышло пока по таким-то и таким-то причинам. B>И вообще, меня больше интересовали ГРАНИЦЫ ПРИМЕНИМОСТИ ПАРАДИГМ ПРОГРАММИРОВАНИЯ, ООБД тут лишь постольку поскольку.
Не, нифига. Ты критиковал ООП за его навигационную сущность. Поскольку наличие чего-то не может мешать, ставим вопрос ребром: какой вид доступа тебе нужен? Я просто более узкий вопрос сначала задавал, типа "хватит ли вот такого доступа"? Сейчас я что-то подумал — а может, я зря так давлю?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
B>>Самый страшный вопрос, как это не печально. Никогда, похоже, ООБД не сравнятся с РСУБД в способности гибко описывать данные реального мира (например, в бизнес-приложениях)
Самый смех заключается в Том, что сделать объектную надстройку над СУБД легче легкого по отношению к локальным базам (в том числе и своим при внутрипроцессорном доступе ), Но пока невозможно для SQL наверное из-за безопасности.
Пока как я понял в Юконе даже применение Net ведется в своем домене и доступ к данным не является самым прямым S>Вот это очень странно. А что такого есть в РСУБД, чего нет в ООП? На мой взгляд, полноценная ООСУБД должна
сводиться к РСУБД в частном случае отказа от наследования, инкапсуляции и полиморфизма. В Java это невозможно, но возможно в С++ и .Net. Берем произвольную реляционную модель, "гибко описывающую данные реального мира". А теперь заменяем все таблички на struct-ы, а форейн кеи на указатели. Ну ладно, триггеры есть — нет проблем, заворачиваем поля в свойства, код триггера пишем в сеттер. С какого момента появляется негибкость?
и солнце б утром не вставало, когда бы не было меня
S>Это близкий к реальному код на C# 2.0. При этом независимо от количества реализаций интерфейса IEmployee результирующая коллекция будет содержать все удовлетворяющие условию объекты.
Действительно похоже на GemStone.
Могут ли классы создаваться на сервере, или только на клиенте? Запросы строятся на основе анализа байт-кода?
И чем вам GemStone не подошел, что решили его повторить?
Здравствуйте, _vovin, Вы писали: _>Действительно похоже на GemStone. _>Могут ли классы создаваться на сервере, или только на клиенте?
Только на сервере _>Запросы строятся на основе анализа байт-кода?
Ага _>И чем вам GemStone не подошел, что решили его повторить?
А тем, что его реализация крайне неэффективна. Подобный код приведет к невозможности использовать индексы. Использование индексов возможно только в случае прямого использования атрибутов в предикате, а это как раз эквивалентно отказу от инкапсуляции и возврату к RDBMS.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
. S>Не, нифига. Ты критиковал ООП за его навигационную сущность. Поскольку наличие чего-то не может мешать, ставим вопрос ребром: какой вид доступа тебе нужен? Я просто более узкий вопрос сначала задавал, типа "хватит ли вот такого доступа"? Сейчас я что-то подумал — а может, я зря так давлю?
1) Давить Вы можете сколько угодно — я постараюсь не поддаваться на провокации . Сорри.
2) Наличие чего-то МОЖЕТ помешать, будьте уверены. Хотя бы увеличением сложности.
3) Я понимаю Ваше искреннее желание узнать, что именно нужно программисту от Вашей базы данных, однако, мне очень трудно помочь Вам в данном вопросе. Если бы я в точности знал, какой метод доступа мне подошел бы больше, чем реляционный, я давным-давно реализовал бы этот метод в своей БД. Ситуация такова, что реляционный подход еще худо-бедно укладывается в моей головенке, а вот что-то большее уже влазиит с трудом.
4) Все таки, либо давайте выделим это обсуждение в отдельную ветку в форуме "БД", либо вернемся к границам парадигм программирования. Как-то мы незаметно ушли от основного вопроса.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _vovin, Вы писали: _>>Действительно похоже на GemStone. _>>Могут ли классы создаваться на сервере, или только на клиенте? S>Только на сервере _>>Запросы строятся на основе анализа байт-кода? S>Ага
Т.е. это вроде хранимых процедур на C#?
Как выглядит процедура деплоймента кода на сервер? Отладка?
_>>И чем вам GemStone не подошел, что решили его повторить? S>А тем, что его реализация крайне неэффективна. Подобный код приведет к невозможности использовать индексы. Использование индексов возможно только в случае прямого использования атрибутов в предикате, а это как раз эквивалентно отказу от инкапсуляции и возврату к RDBMS.
В чем у вас отличия от GemStone? При использовании пропертей/методов с прямым возвратом атрибута идет использование индекса атрибута? Делается ли преобразование сложного предиката к виду, когда становится возможным использование индекса?
В любом случае полностью инкапсулировать способ представления данных не получится. Пользователь класса Employee должен по-крайней мере знать, будет ли задействован индекс при использовании свойства Salary или нет. А это уже зависит от того, является ли это хранимым полем или сложновычисляемым значением.
Лучше всего добиваться полной инкапсуляции выведением всех запросов в одно место — обычно в методы на стороне класса.
[code]
Employee class>>highPayedEmployees
^allEmployees select: {:emp | emp.salary > 500}
[code]
_>Т.е. это вроде хранимых процедур на C#?
Не, это вроде методов объектов.
Чтобы предупредить недопонимание: все еще в стадии research. Т.е. это не только не альфа, это еще даже архитектура не продумана. _>Как выглядит процедура деплоймента кода на сервер? Отладка?
Unknown yet.
_>В чем у вас отличия от GemStone? При использовании пропертей/методов с прямым возвратом атрибута идет использование индекса атрибута?
Да. _> Делается ли преобразование сложного предиката к виду, когда становится возможным использование индекса?
Да.
_>В любом случае полностью инкапсулировать способ представления данных не получится. Пользователь класса Employee должен по-крайней мере знать, будет ли задействован индекс при использовании свойства Salary или нет.
Зачем? Это не его проблема. _> А это уже зависит от того, является ли это хранимым полем или сложновычисляемым значением.
Ну, в общем случае да. _>Лучше всего добиваться полной инкапсуляции выведением всех запросов в одно место — обычно в методы на стороне класса.
В таком случае никаких преимуществ у ODBMS не будет. Это просто замена названия "хранимая процедура" на название "метод класса". _>[code] _>Employee class>>highPayedEmployees _> ^allEmployees select: {:emp | emp.salary > 500} _>[code]
Отстой. Именно от этого я хочу уйти. Потому, что мы говорим вообще об интерфейсе IEmployee. Для алгоритма, который выступает клиентом IEmployee, совершенно по барабану, кто и какими способами его реализует. Это позволяет расширять систему. В твоем варианте у нас будут вшитые в Емплое методы, которые работают эффективно. Попытка сделать свой метод lowPayedEmployees не удастся, либо будет низкопроизводительной. А если у нас сосуществуют несколько реализаций IEmployee?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _vovin, Вы писали:
_>>Т.е. это вроде хранимых процедур на C#? S>Не, это вроде методов объектов. S>Чтобы предупредить недопонимание: все еще в стадии research. Т.е. это не только не альфа, это еще даже архитектура не продумана. _>>Как выглядит процедура деплоймента кода на сервер? Отладка? S>Unknown yet.
Если все еще настолько неразработано, то я бы посоветовал бросить идею написать супер-ООБД. Если только у вас нет неограниченного источника финансирования.
_>>В чем у вас отличия от GemStone? При использовании пропертей/методов с прямым возвратом атрибута идет использование индекса атрибута? S>Да. _>> Делается ли преобразование сложного предиката к виду, когда становится возможным использование индекса? S>Да.
_>>В любом случае полностью инкапсулировать способ представления данных не получится. Пользователь класса Employee должен по-крайней мере знать, будет ли задействован индекс при использовании свойства Salary или нет. S>Зачем? Это не его проблема.
Его проблемой станет тормознутый запрос.
Например к генератору отчетов формулируются требование — собрать такую-то информацию за такой-то период и сделать это быстро. Автоматически ко всем запросам ставится требование выполняться быстро. Значит на больших объемах необходимо использовать индекс. Соответственно генератор запросов должен иметь некоторое представление о структуре объектов и в каких случаях возможно использование индекса.
Поэтому инкапсулировать все не получится.
_>> А это уже зависит от того, является ли это хранимым полем или сложновычисляемым значением. S>Ну, в общем случае да. _>>Лучше всего добиваться полной инкапсуляции выведением всех запросов в одно место — обычно в методы на стороне класса. S>В таком случае никаких преимуществ у ODBMS не будет. Это просто замена названия "хранимая процедура" на название "метод класса". _>>[code] _>>Employee class>>highPayedEmployees _>> ^allEmployees select: {:emp | emp.salary > 500} _>>[code]
S>Отстой. Именно от этого я хочу уйти. Потому, что мы говорим вообще об интерфейсе IEmployee. Для алгоритма, который выступает клиентом IEmployee, совершенно по барабану, кто и какими способами его реализует. Это позволяет расширять систему. В твоем варианте у нас будут вшитые в Емплое методы, которые работают эффективно. Попытка сделать свой метод lowPayedEmployees не удастся, либо будет низкопроизводительной. А если у нас сосуществуют несколько реализаций IEmployee?
Employee class можно с успехом заменить на EmployeeList, а allEmployees будет хранить список всех работников всевозможных реализаций. Ты же в курсе, что в GemStone коллекцию можно заполнить любыми элементами, и там нет соответствия класс<->таблица. В общем код пишется как в обычном Smalltalk-е.
В дальнейшем EmployeeList не проблема расширить новыми методами, которые будут реализованы эффективно. Естественно там будет использовано знание внутренней структуры объектов. Но это знание будет локализовано.
Соглашусь, что твоя реализация (будущая?) содержит некоторую новизну (идейно все уже придумано до нас) и она способна устранить некоторые проблемы. Например, тот же полиморфизм, нетривиальные предикаты и прочее. Вполне очевидный шаг.
Но и проблем тут больше чем хотелось бы. Например, сложные предикаты актуальны и для RDBMS. Но никто не парится с ними что-то делать, при их-то ресурсах. Гораздо продуктивнее не писать "общую программу", а решить частную проблему дешевым способом.
Так же и с инкапсуляцией/полиморфизмом в ООБД. Проще задействовать кэширование и прямой доступ к полям, чем писать универсальный анализатор предикатов, скрещиватель разных индексов и т.д.
По трудоемкости такой проект в сравнении с обычной БД, как HotSpot в сравнении с обычной VM.
Здравствуйте, _vovin, Вы писали:
S>>Зачем? Это не его проблема.
_>Его проблемой станет тормознутый запрос. _>Например к генератору отчетов формулируются требование — собрать такую-то информацию за такой-то период и сделать это быстро. Автоматически ко всем запросам ставится требование выполняться быстро. Значит на больших объемах необходимо использовать индекс. Соответственно генератор запросов должен иметь некоторое представление о структуре объектов и в каких случаях возможно использование индекса. _>Поэтому инкапсулировать все не получится.
Очень странно. А почему тогда подобная проблема не возникает в RDBMS приложениях? Мой богатый опыт говорит о примерно следующей последовательности событий:
1. На основе функциональных требований проектируется схема данных (как правило, сильно нормализованная)
2. Реализуется бизнес- и презентационная логика
3. Готовый комплект тестируется и выполняются QA работы
4. Если необходимость, то выполняются performance тесты
5. Если выявилась необходимость, то выполняется тюнинг базы
5.1. Смотрим планы запросов, которые необходимо ускорить.
5.2. При помощи расстановки индексов добиваемся нужной производительности
5.3. Если все еще недостаточно, применяем денормализации.
Пункт 5.3. вводится в действие очень редко.
Так вот, обрати внимание, что п.5 выполняется на стадии эксплуатации. И прелесть в том, что никакому Кристал, и даже девелоперу, ответственному за репорты, ни про какие индексы знать ничего не надо. Так что мне в данном контексте неясно, почему для разработчика отчетов вдруг появится необходимость в превентивном знании индексов при использовании ODBMS.
Знание индексов необходимо движку. _>Employee class можно с успехом заменить на EmployeeList, а allEmployees будет хранить список всех работников всевозможных реализаций. Ты же в курсе, что в GemStone коллекцию можно заполнить любыми элементами, и там нет соответствия класс<->таблица. В общем код пишется как в обычном Smalltalk-е.
Это я в курсе. Я также в курсе, что мне придется все это делать руками. И вручную выполнять union для запросов по различным классам. Это означает, что при добавлении нового класса я обязан пересмотреть (и переписать!!!) все запросы. Это и есть то, что я называю отстоем. То же самое я могу реализовать в MS SQL. Меня как раз бесит необходимость переписывать большое количество хранимых процедур при минимальных изменениях в дизайне. _>В дальнейшем EmployeeList не проблема расширить новыми методами, которые будут реализованы эффективно.
Нет. Это противоречит принципу компонентности. Ты искусственно ограничиваешь возможности пользователей твоего класса. Более того, никто, кроме автора класса Employee не сможет добавить наследника. _>Соглашусь, что твоя реализация (будущая?) содержит некоторую новизну (идейно все уже придумано до нас) и она способна устранить некоторые проблемы. Например, тот же полиморфизм, нетривиальные предикаты и прочее. Вполне очевидный шаг.
_>Но и проблем тут больше чем хотелось бы. Например, сложные предикаты актуальны и для RDBMS. Но никто не парится с ними что-то делать, при их-то ресурсах. Гораздо продуктивнее не писать "общую программу", а решить частную проблему дешевым способом.
Нет. Дело в том, что в RDBMS всегда доступны "исходники", т.е. мы можем вручную перестроить запрос. Нафига обучать оптимизатор разбирать предикаты вида a + 5 > 5, когда такой предикат может появиться только прихотью программиста? Дешевле написать один абзац в мануле со словами "заменяйте a + @a < @b на a < (@b-@a), иначе нельзя будет использовать индекс". _>Так же и с инкапсуляцией/полиморфизмом в ООБД. Проще задействовать кэширование и прямой доступ к полям, чем писать универсальный анализатор предикатов, скрещиватель разных индексов и т.д. _>По трудоемкости такой проект в сравнении с обычной БД, как HotSpot в сравнении с обычной VM.
Совершенно верно. Вот только "обычные" ODBMS нафиг никому не уперлись. Я подписался на рассылку GemStone. Ребята, там трафик меньше, чем в форуме по R#.
В общем, пока что я в самом начале. Намечены только контуры будущих работ... Но если получится.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _vovin, Вы писали:
S>>>Зачем? Это не его проблема.
_>>Его проблемой станет тормознутый запрос. _>>Например к генератору отчетов формулируются требование — собрать такую-то информацию за такой-то период и сделать это быстро. Автоматически ко всем запросам ставится требование выполняться быстро. Значит на больших объемах необходимо использовать индекс. Соответственно генератор запросов должен иметь некоторое представление о структуре объектов и в каких случаях возможно использование индекса. _>>Поэтому инкапсулировать все не получится. S>Очень странно. А почему тогда подобная проблема не возникает в RDBMS приложениях? Мой богатый опыт говорит о примерно следующей последовательности событий: S>1. На основе функциональных требований проектируется схема данных (как правило, сильно нормализованная) S>2. Реализуется бизнес- и презентационная логика S>3. Готовый комплект тестируется и выполняются QA работы S>4. Если необходимость, то выполняются performance тесты S>5. Если выявилась необходимость, то выполняется тюнинг базы S>5.1. Смотрим планы запросов, которые необходимо ускорить. S>5.2. При помощи расстановки индексов добиваемся нужной производительности S>5.3. Если все еще недостаточно, применяем денормализации.
S>Пункт 5.3. вводится в действие очень редко. S>Так вот, обрати внимание, что п.5 выполняется на стадии эксплуатации. И прелесть в том, что никакому Кристал, и даже девелоперу, ответственному за репорты, ни про какие индексы знать ничего не надо. Так что мне в данном контексте неясно, почему для разработчика отчетов вдруг появится необходимость в превентивном знании индексов при использовании ODBMS.
S>Знание индексов необходимо движку.
Все это хорошо в предположении, что добавление индексов решает проблему. Но в случае, когда избрана стратегия реализации, в принципе не позволяющая быстро сделать вот этот пользовательский запрос, всплывший позднее, то никакими тюнингами базы делу не поможешь.
В большинстве случаев у тебя явно где-то подсознательно при реализации всей функциональности автоматически выполняется требование по возможности делать "хорошие" запросы. Просто ты его не документируешь явно, но от этого оно никуда не исчезает.
_>>Employee class можно с успехом заменить на EmployeeList, а allEmployees будет хранить список всех работников всевозможных реализаций. Ты же в курсе, что в GemStone коллекцию можно заполнить любыми элементами, и там нет соответствия класс<->таблица. В общем код пишется как в обычном Smalltalk-е. S>Это я в курсе. Я также в курсе, что мне придется все это делать руками. И вручную выполнять union для запросов по различным классам. Это означает, что при добавлении нового класса я обязан пересмотреть (и переписать!!!) все запросы. Это и есть то, что я называю отстоем. То же самое я могу реализовать в MS SQL. Меня как раз бесит необходимость переписывать большое количество хранимых процедур при минимальных изменениях в дизайне.
Ты опять наверное предполагаешь соответствие: один класс — один список объектов. Тут нет аналогии с RDBMS. Ты сам создаешь коллекцию и добавляешь туда любые объекты. В разнородных коллекция работают и полиморфизм и индексы по полям.
_>>В дальнейшем EmployeeList не проблема расширить новыми методами, которые будут реализованы эффективно. S>Нет. Это противоречит принципу компонентности. Ты искусственно ограничиваешь возможности пользователей твоего класса. Более того, никто, кроме автора класса Employee не сможет добавить наследника.
Компонентность тут параллельна, GemStone это чисто объектная система и понимание модульности там со своей спецификой.
В данном случае поля объекта объявляются публичным интерфейсом по отношению к классу EmployeeList (в этом месте слегка жертвуем инкапсуляцией). Этот класс расширяется другими модулями для получения необходимой функциональности.
Цель локализовать знание структуры и минимизировать зависимости достигнута.
Ты предлагаешь более развитую модель ООБД, чтобы сделать это лучше.
Но если эта новая ООБД не является самоцелью или отдельным перспективным продуктом, то я не вижу существенного основания писать ее.
_>>Соглашусь, что твоя реализация (будущая?) содержит некоторую новизну (идейно все уже придумано до нас) и она способна устранить некоторые проблемы. Например, тот же полиморфизм, нетривиальные предикаты и прочее. Вполне очевидный шаг.
_>>Но и проблем тут больше чем хотелось бы. Например, сложные предикаты актуальны и для RDBMS. Но никто не парится с ними что-то делать, при их-то ресурсах. Гораздо продуктивнее не писать "общую программу", а решить частную проблему дешевым способом. S>Нет. Дело в том, что в RDBMS всегда доступны "исходники", т.е. мы можем вручную перестроить запрос. Нафига обучать оптимизатор разбирать предикаты вида a + 5 > 5, когда такой предикат может появиться только прихотью программиста? Дешевле написать один абзац в мануле со словами "заменяйте a + @a < @b на a < (@b-@a), иначе нельзя будет использовать индекс".
А что если a * a < 5 или Log(a) < 5?
_>>Так же и с инкапсуляцией/полиморфизмом в ООБД. Проще задействовать кэширование и прямой доступ к полям, чем писать универсальный анализатор предикатов, скрещиватель разных индексов и т.д. _>>По трудоемкости такой проект в сравнении с обычной БД, как HotSpot в сравнении с обычной VM. S>Совершенно верно. Вот только "обычные" ODBMS нафиг никому не уперлись. Я подписался на рассылку GemStone. Ребята, там трафик меньше, чем в форуме по R#.
Специфика продукта такая. Лицензия дорогая, поэтому есть только профессионалы, которые пишут по другим каналам или уже все гуру.
S>В общем, пока что я в самом начале. Намечены только контуры будущих работ... Но если получится.
Советую завести блог и отражать там прогресс мысли и реализации. Много полезного фидбэка можно получить таким образом.
Здравствуйте, _vovin, Вы писали: _>Все это хорошо в предположении, что добавление индексов решает проблему. Но в случае, когда избрана стратегия реализации, в принципе не позволяющая быстро сделать вот этот пользовательский запрос, всплывший позднее, то никакими тюнингами базы делу не поможешь.
Ну да. Я же написал про случай 5.3. Там уже начинаем переколбашивать структуру (ясно-понятно, что уже в пятом проекте архитектор начинает угадывать 90% будущих особенностей ). _>В большинстве случаев у тебя явно где-то подсознательно при реализации всей функциональности автоматически выполняется требование по возможности делать "хорошие" запросы. _> Просто ты его не документируешь явно, но от этого оно никуда не исчезает.
_>Ты опять наверное предполагаешь соответствие: один класс — один список объектов.
Нет, не предполагаю. _>Тут нет аналогии с RDBMS. Ты сам создаешь коллекцию и добавляешь туда любые объекты. В разнородных коллекция работают и полиморфизм и индексы по полям.
Очень интересно. В той доке, которую я читал, было написано, что во-первых индексы используются только для запросов на точное совпадение. А во-вторых, нельзя использовать в предикате вызовы методов:
An operand can be a path (anEmployee.name, in this case), a variable name, or a
literal (’Fred’, in this example).
(GemStone/S Programming Guide, Section 5.2 "Selection Blocks and Selection")
Это означает, что я не смогу в такой смешанной коллекции отфильтровать классы по
Потому как getSalary — это метод. _>Компонентность тут параллельна, GemStone это чисто объектная система и понимание модульности там со своей спецификой. _>В данном случае поля объекта объявляются публичным интерфейсом по отношению к классу EmployeeList (в этом месте слегка жертвуем инкапсуляцией).
Нифига себе "слегка". Это из области "он оказался немножко мертвым". Заодно мы пожертвовали полиморфизмом, т.к. поле уже задало единственную реализацию, и мы не можем ее поменять. _>Этот класс расширяется другими модулями для получения необходимой функциональности. _>Цель локализовать знание структуры и минимизировать зависимости достигнута.
А заодно мы получили железобетонный монолит. _>Ты предлагаешь более развитую модель ООБД, чтобы сделать это лучше. _>Но если эта новая ООБД не является самоцелью или отдельным перспективным продуктом, то я не вижу существенного основания писать ее.
Гм. По-моему, это попытка найти выход из тупика.
_>А что если a * a < 5 или Log(a) < 5?
Хороший вопрос. Я над ним думаю.
_>Специфика продукта такая. Лицензия дорогая, поэтому есть только профессионалы, которые пишут по другим каналам или уже все гуру. S>>В общем, пока что я в самом начале. Намечены только контуры будущих работ... Но если получится. _>Советую завести блог и отражать там прогресс мысли и реализации. Много полезного фидбэка можно получить таким образом.
Интересная мысль. Боюсь, такая ответственная работа, как ведение блога, мне пока что недоступна. Не умею я этого.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _vovin, Вы писали: _>>Все это хорошо в предположении, что добавление индексов решает проблему. Но в случае, когда избрана стратегия реализации, в принципе не позволяющая быстро сделать вот этот пользовательский запрос, всплывший позднее, то никакими тюнингами базы делу не поможешь. S>Ну да. Я же написал про случай 5.3. Там уже начинаем переколбашивать структуру (ясно-понятно, что уже в пятом проекте архитектор начинает угадывать 90% будущих особенностей ). _>>В большинстве случаев у тебя явно где-то подсознательно при реализации всей функциональности автоматически выполняется требование по возможности делать "хорошие" запросы. _>> Просто ты его не документируешь явно, но от этого оно никуда не исчезает.
_>>Ты опять наверное предполагаешь соответствие: один класс — один список объектов. S>Нет, не предполагаю. _>>Тут нет аналогии с RDBMS. Ты сам создаешь коллекцию и добавляешь туда любые объекты. В разнородных коллекция работают и полиморфизм и индексы по полям. S>
S>Очень интересно. В той доке, которую я читал, было написано, что во-первых индексы используются только для запросов на точное совпадение. А во-вторых, нельзя использовать в предикате вызовы методов: S>
An operand can be a path (anEmployee.name, in this case), a variable name, or a
S>literal (’Fred’, in this example).
S>(GemStone/S Programming Guide, Section 5.2 "Selection Blocks and Selection") S>Это означает, что я не смогу в такой смешанной коллекции отфильтровать классы по S>
Table 5.1 Comparison Operators Allowed in a Selection Block
== Identity comparison operator
= Equality comparison operator, case-sensitive
< Less than equality operator, case-insensitive
<= Less than or equal to equality operator, caseinsensitive
> Greater than equality operator, case-insensitive
>= Greater than or equal to equality operator, caseinsensitive
Далее про сообщения:
myEmployees select: [:anEmployee | anEmployee age = 40]
Searching for an object by content or value instead of by name or location is called
associative access.
The searching messages defined by Collection must send one or more messages for
each element of the receiver. Executing the expression given above requires
sending the messages age and = for each element of myEmployees. This strategy
is suitable for small collections, but it can be too slow for a collection containing
thousands of complex elements.
For efficient associative access to large collections, it’s useful to build an external
index for them. Indexing a Collection creates structures such as balanced trees that
let you find values without waiting for sequential searches. Indexing structures
can retrieve the objects you require by sending many fewer messages—ideally,
only the minimum number necessary. Indexes allow you faster access to large
UnorderedCollections because when such collections are indexed, they can
respond to queries using select:, detect:, or reject: without sending
messages for every element of the receiver.
Т.е. сообщения посылать можешь, но при этом идет полный скан. Если хочешь индекс, используй instance variable path.
_>>Компонентность тут параллельна, GemStone это чисто объектная система и понимание модульности там со своей спецификой. _>>В данном случае поля объекта объявляются публичным интерфейсом по отношению к классу EmployeeList (в этом месте слегка жертвуем инкапсуляцией). S>Нифига себе "слегка". Это из области "он оказался немножко мертвым". Заодно мы пожертвовали полиморфизмом, т.к. поле уже задало единственную реализацию, и мы не можем ее поменять.
Это жестокая реальность баз данных. Если ты хочешь делать запрос на больших данных, то ты должен быть уверен, что твои условия хорошо положатся на индексы. Т.е. к методам, участвующим в запросах, должно предъявляться дополнительное требование.
В случае GemStone — такой метод должен возвращать одноименный атрибут и на него должен быть индекс.
В случае "идеальной" ООБД — метод должен являться выражением, которое может быть "в достаточной мере" соптимизировано движком БД. Достаточная мера опять же должна быть как-то определена. Типа отсутствие полного скана, log(N), N*log(N) или что-либо другое.
Ты забываешь, что далеко не все методы участвуют в запросах, большинство из них нужно только чтобы выдавать какие-то данные. А там уже полиморфизм c инкапсуляцией применимы во всей своей красе.
_>>Этот класс расширяется другими модулями для получения необходимой функциональности. _>>Цель локализовать знание структуры и минимизировать зависимости достигнута. S>А заодно мы получили железобетонный монолит. _>>Ты предлагаешь более развитую модель ООБД, чтобы сделать это лучше. _>>Но если эта новая ООБД не является самоцелью или отдельным перспективным продуктом, то я не вижу существенного основания писать ее. S>Гм. По-моему, это попытка найти выход из тупика.
Тупик это громко сказано.
Например в случае с RDBMS и даже O/R маппинга все что мы имеем — это value objects, замапленные на конкретные таблицы и конкретные поля. Т.е. тут вообще отсутствует какая либо инкапсуляция и какой-либо полиморфизм. Вот уж где тупик.
GemStone же позволяет инкапсулировать все, но если по чем-то тебе нужно вести поиск, то тут ты оказываешься ограничен реализацией. Сложно вычисляемые значения должны кэшироваться в атрибуты, которые должны быть доступны объекту, ответственному за запросы.
_>>А что если a * a < 5 или Log(a) < 5? S>Хороший вопрос. Я над ним думаю.
Подумай, но в таких запущенных случаях думаю придешь к подходу применимому и в GemStone — кэширование сложных выражений в отдельных атрибутах.
_>>Специфика продукта такая. Лицензия дорогая, поэтому есть только профессионалы, которые пишут по другим каналам или уже все гуру. S>>>В общем, пока что я в самом начале. Намечены только контуры будущих работ... Но если получится. _>>Советую завести блог и отражать там прогресс мысли и реализации. Много полезного фидбэка можно получить таким образом. S>Интересная мысль. Боюсь, такая ответственная работа, как ведение блога, мне пока что недоступна. Не умею я этого.
Ничего сложного. Где-нибудь на LiveJournal открываешь блог, даешь ссылку нужным людям с теми же интересами, пишешь мысли, люди в комментах пишут отзывы. Проще не придумаешь, а польза значительная.
Как вариант в форуме DB открываешь соответствующую тему. Но формат форума не так хорош, там посты автора затусовываются в общей свалке. Плюс ограничить доступ к переписке нельзя.
Здравствуйте, _vovin, Вы писали:
_>Здравствуйте, Sinclair, Вы писали: _>Насчет совпадения, вот цитата оттуда же: _>
_>Table 5.1 Comparison Operators Allowed in a Selection Block
_>== Identity comparison operator
_>= Equality comparison operator, case-sensitive
_>< Less than equality operator, case-insensitive
_><= Less than or equal to equality operator, caseinsensitive
>> Greater than equality operator, case-insensitive
>>= Greater than or equal to equality operator, caseinsensitive
Это я читал. Вот только тут не сказано, что будет использоваться индекс. Я прозрачно намекаю? _>Т.е. сообщения посылать можешь, но при этом идет полный скан. Если хочешь индекс, используй instance variable path.
Я так и понял. Вот я и хочу построить систему, которая бы давала выполнять произвольные сравнения, в том числе Name.BeginsWith("Geor"), и с посылкой сообщений, и все с неменьшей, чем RDBMS эффективностью. _>Это жестокая реальность баз данных. Если ты хочешь делать запрос на больших данных, то ты должен быть уверен, что твои условия хорошо положатся на индексы. _>Т.е. к методам, участвующим в запросах, должно предъявляться дополнительное требование.
Да. На мой взгляд, вполне достаточно запретить в них изменять состояние персистентных объектов. _>В случае GemStone — такой метод должен возвращать одноименный атрибут и на него должен быть индекс.
Ну, научная сторона работы — собственно, в формулировке тех ограничений, которые являются следствием неумолимой математики, а не ограниченности разработчиков. Если такие ограничения вообще есть. Кстати, а откуда дровишки про "такой метод должен возвращать одноименный атрибут и на него должен быть индекс"? В доке ничего не сказано про возможность использовать методы в select-блоке вообще. _>В случае "идеальной" ООБД — метод должен являться выражением, которое может быть "в достаточной мере" соптимизировано движком БД. Достаточная мера опять же должна быть как-то определена. Типа отсутствие полного скана, log(N), N*log(N) или что-либо другое.
_>Ты забываешь, что далеко не все методы участвуют в запросах, большинство из них нужно только чтобы выдавать какие-то данные. А там уже полиморфизм c инкапсуляцией применимы во всей своей красе.
Вот это на мой взгляд как раз очень плохо — разделение методов на "для поиска" и "для выдачи". Я приводил пример с потомками класса Employee.
Есть решение, подходящее для GemStone (впрочем, и для RDBMS) и приемлемое по производительности. Но оно предполагает массу ручной работы при малейшем изменении, и крайне чувствительно к ошибкам разработчика. _>Тупик это громко сказано. _>Например в случае с RDBMS и даже O/R маппинга все что мы имеем — это value objects, замапленные на конкретные таблицы и конкретные поля. Т.е. тут вообще отсутствует какая либо инкапсуляция и какой-либо полиморфизм. Вот уж где тупик.
Нц почему. Точно так же можно сделать в этих объектах полиморфные методы, которые не отображаются в поля базы, а вычисляются по произвольному алгоритму. И ничто не мешает нам использовать их даже в запросах. Вот только это будет полный скан. Ничего не напоминает? _>GemStone же позволяет инкапсулировать все, но если по чем-то тебе нужно вести поиск, то тут ты оказываешься ограничен реализацией. Сложно вычисляемые значения должны кэшироваться в атрибуты, которые должны быть доступны объекту, ответственному за запросы.
_>>>А что если a * a < 5 или Log(a) < 5? S>>Хороший вопрос. Я над ним думаю.
_>Подумай, но в таких запущенных случаях думаю придешь к подходу применимому и в GemStone — кэширование сложных выражений в отдельных атрибутах.
Ну, эта-то возможность всегда остается.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
_>Тупик это громко сказано. _>Например в случае с RDBMS и даже O/R маппинга все что мы имеем — это value objects, замапленные на конкретные таблицы и конкретные поля. Т.е. тут вообще отсутствует какая либо инкапсуляция и какой-либо полиморфизм. Вот уж где тупик.
Ну не совсем так. Если рассматривать строку таблицы как объект (занимаемая область памяти в бкфере или страницы), то различий в общем то никаких (Сишных объектах, packet object). Таже инкапсуляция за счет добавления полей.
Второй вариант это виртуальные свойства и применение подчиненных таблиц. Все премущества индексов можно использовать. Только вот применение SQL в данном случае весьма сомнительно, хотя ....
и солнце б утром не вставало, когда бы не было меня