Comments 17
Раз одна поддерживает SQL, напишите JDBC драйвер, или хотя бы ODBC. Или уже есть?
Расскажите, пожалуйста, чем это лучше связки MS SQL Server и Linq2SQL/EF/NHibernate?
Благодарю за хороший вопрос.
В данном случае Вы имеете дело с базой данных напрямую, без MS SQL Server'а (который, кстати, нужно лицензировать отдельно), поэтому нет дополнительных слоев доступа к данным, которые замедляют работу (и иногда нарушают логику объектов). Eloquera манипулирует объектами напрямую — ради скорости.
Microsoft прекращает развитие Linq2SQL (не самого LINQ, конечно) из-за неудовлетворительного качества SQL-кода и необходимости прямого доступа к таблицам. Entity Framework — хорошая штука, требующая, правда, генерации файлов описания данных, что делает обновление схемы несколько муторным занятием. NHibernate — это классический O/R Mapper со всеми вытекающими отсюда потенциальными проблемами.
Eloquera будет поддерживать LINQ (мы работаем над этим), и поддерживать его эффективно, без генерации SQL, поскольку LINQ — практически идеальный язык для объектных запросов. В планах так же есть поддержка EF, а также других объектных платформ (к примеру, Java). Опять же, благодаря непосредственной работе с объектами, многие «родовые» проблемы LINQ2SQL и EF решаются довольно эффективно.
В данном случае Вы имеете дело с базой данных напрямую, без MS SQL Server'а (который, кстати, нужно лицензировать отдельно), поэтому нет дополнительных слоев доступа к данным, которые замедляют работу (и иногда нарушают логику объектов). Eloquera манипулирует объектами напрямую — ради скорости.
Microsoft прекращает развитие Linq2SQL (не самого LINQ, конечно) из-за неудовлетворительного качества SQL-кода и необходимости прямого доступа к таблицам. Entity Framework — хорошая штука, требующая, правда, генерации файлов описания данных, что делает обновление схемы несколько муторным занятием. NHibernate — это классический O/R Mapper со всеми вытекающими отсюда потенциальными проблемами.
Eloquera будет поддерживать LINQ (мы работаем над этим), и поддерживать его эффективно, без генерации SQL, поскольку LINQ — практически идеальный язык для объектных запросов. В планах так же есть поддержка EF, а также других объектных платформ (к примеру, Java). Опять же, благодаря непосредственной работе с объектами, многие «родовые» проблемы LINQ2SQL и EF решаются довольно эффективно.
Ммм а как это все храниться?
Возможно ли в будущем сделать секцию объектов в базе напоминающие/являющимися процедурами?
Не для конкретной базы, а так сказать спецификативно описать, чтобы во всех базах была по умолчанию?
А да, и что требуется на конечном компьютере? Доп библиотеки или что?
Ну и самый интересный вопрос, есть полнотекстовый поиск? со словоформами итп?
Возможно выражаюсь, некорректно извините…
Возможно ли в будущем сделать секцию объектов в базе напоминающие/являющимися процедурами?
Не для конкретной базы, а так сказать спецификативно описать, чтобы во всех базах была по умолчанию?
А да, и что требуется на конечном компьютере? Доп библиотеки или что?
Ну и самый интересный вопрос, есть полнотекстовый поиск? со словоформами итп?
Возможно выражаюсь, некорректно извините…
FROM functionality is not implemented yet ммм… мозг выпал в осадок…
Запросы вида
вполне работают.
Вы правы, если исполнить запрос вида
то система вернет ошибку
FROM functionality is not implemented yet,
что не совсем точно определяет проблему. А проблема в том, что C# (как и многие другие мейнстрим-языки .NET) не допускает динамических типов во время исполнения, т.е. компилятор должен знать, какой тип вернет тот или иной метод, или к какому типу выполнить приведение (type casting). Поэтому запросы сейчас возвращают только экземпляры классов, но не отдельные их поля или свойства. При использовании LINQ компилятор сам генерирует возвращаемые классы во время компиляции, т.е. опять нет динамической типизации. В C# 4.0 появилась возможность использовать динамические типы, так что полноценный SELECT… FROM — не за горами.
Берегите мозг — говорят, без него тяжело! :-)
SELECT * FROM Paper
вполне работают.
Вы правы, если исполнить запрос вида
SELECT Publisher FROM Paper
то система вернет ошибку
FROM functionality is not implemented yet,
что не совсем точно определяет проблему. А проблема в том, что C# (как и многие другие мейнстрим-языки .NET) не допускает динамических типов во время исполнения, т.е. компилятор должен знать, какой тип вернет тот или иной метод, или к какому типу выполнить приведение (type casting). Поэтому запросы сейчас возвращают только экземпляры классов, но не отдельные их поля или свойства. При использовании LINQ компилятор сам генерирует возвращаемые классы во время компиляции, т.е. опять нет динамической типизации. В C# 4.0 появилась возможность использовать динамические типы, так что полноценный SELECT… FROM — не за горами.
Берегите мозг — говорят, без него тяжело! :-)
Можно было бы сделать что-то вроде неполной загрузки объектов. Т. е.
SELECT Publisher FROM Paper будет возвращать всё тот же массив с Paper, но заполненным у объектов будет только поле Publisher, а остальные «как-нибудь так, как-нибудь так».Да, верно, это сработало бы для полей, но не для свойств (properties), которые могут быть «только для чтения» (read-only) или вычисляемыми из нескольких других полей или свойств. Этот вариант у нас частично реализован, но отключен из-за «неинтуитивности».
Многочисленные беседы с программистами показали, что большинство ожидает, что запрос
Как Вы считаете, является ли этот путь более «интуитивным» и/или корректным?
Многочисленные беседы с программистами показали, что большинство ожидает, что запрос
SELECT Publisher FROM Paper вернет массив string[], а запрос SELECT Publisher, CopiesPublished FROM Paper должен вернуть массив экземпляров динамического класса типа {string Publisher, int CopiesPublished }[].Как Вы считаете, является ли этот путь более «интуитивным» и/или корректным?
именно так я и делал… (SELECT Publisher FROM Paper)
А есть ли DELETE, INSERT, подобие BULK INSERT?
А есть ли DELETE, INSERT, подобие BULK INSERT?
Функциональность для
Delete, Insert и Update реализованы как методы, принимающие объекты в качестве параметров — все же база объектная. С добавлением сложных объектов в основной функционал BULK INSERT можно будет делать, помещая в базу коллекцию объектов — например,
SELECT Publisher FROM Paper будет добавлена чуть позже, возможно, с LINQ и/или EF (хотя, скорее всего, независимо от них).Delete, Insert и Update реализованы как методы, принимающие объекты в качестве параметров — все же база объектная. С добавлением сложных объектов в основной функционал BULK INSERT можно будет делать, помещая в базу коллекцию объектов — например,
object[], что позволит не только вставлять объекты разных типов одновременно, но и позволит реализовать нечто вроде BULK UPDATE и BULK DELETE для объектов любого типа.Данные хранятся на сервере, и каждый пользователь имеет доступ к данным. Для доступа нужен только клиент (.NET-сборка — она использует .NET 2.0 SP1, т.е. в качестве клиентской ОС можно использовать все Windows от 2000 и старше), который можно скачать отдельно.
Мне приходится забегать вперед и писать о том, что мы еще не закончили или даже только собираемся делать, но, видимо, это отличительная черта хабровчан — смотреть в будущее, что не может не радовать. :-) Мы работаем над т.н. «фильтрами» — специального вида классами, которые преобразовывают данные для хранения и/или индексирования в специальном виде. К примеру, один из фильтров — кстати, один из самых простых — преобразует тексты в набор слов в «упрощенном» виде для полнотекстового поиска, правда, пока только на английском. Но мы собираемся выложить интерфейсы фильтров и их исходные тексты в общий доступ и продолжать их разработку в open-source сообществе, так что стоит ожидать появления версии и для русского языка, и других.
Те же фильтры могут выполнять роль хранимых процедур (stored procedure), и возвращать данные в уже преобразованном виде, к примеру, как XML. Эти фильтры могут быть привязаны к одной базе или быть доступными всем базам на данном сервере.
Мне приходится забегать вперед и писать о том, что мы еще не закончили или даже только собираемся делать, но, видимо, это отличительная черта хабровчан — смотреть в будущее, что не может не радовать. :-) Мы работаем над т.н. «фильтрами» — специального вида классами, которые преобразовывают данные для хранения и/или индексирования в специальном виде. К примеру, один из фильтров — кстати, один из самых простых — преобразует тексты в набор слов в «упрощенном» виде для полнотекстового поиска, правда, пока только на английском. Но мы собираемся выложить интерфейсы фильтров и их исходные тексты в общий доступ и продолжать их разработку в open-source сообществе, так что стоит ожидать появления версии и для русского языка, и других.
Те же фильтры могут выполнять роль хранимых процедур (stored procedure), и возвращать данные в уже преобразованном виде, к примеру, как XML. Эти фильтры могут быть привязаны к одной базе или быть доступными всем базам на данном сервере.
очень интересно :)
А сжатие будет?
P.S на днях попробую заюзать…
А сжатие будет?
P.S на днях попробую заюзать…
Открою еще один секрет — мы работаем над потоками бинарных данных, которые можно будет хранить в базе и получать обратно также в виде потока. С помощью фильтров можно будет добавить возможность сжатия бинарных данных.
Сама база по умолчанию не сжимает данные, т.к. ее основная цель — скорость, а сжатие несколько противоречит этой идее.
Буду рад помочь, если возникнут вопросы по базе. В любом случае, буду вести этот блог, по мере возможностей добавляя новые статьи об объектном проектировании.
Сама база по умолчанию не сжимает данные, т.к. ее основная цель — скорость, а сжатие несколько противоречит этой идее.
Буду рад помочь, если возникнут вопросы по базе. В любом случае, буду вести этот блог, по мере возможностей добавляя новые статьи об объектном проектировании.
Подожду введения JOIN'ов.
Sign up to leave a comment.
Eloquera — объектная база с SQL