| [Форум] [Помощь] [Поиск] [Выйти] |
Добро пожаловать, ![[info]](userinfo.gif){kind=small} User
|
|
|
| ||
| Уважаемые, знает ли кто-нибудь СУБД Tamina? Это такая нативная XML-СУБД, что само по себе является очень привлекательным. По идее хранение и операции с XML-объектами в БД должно быть гораздо удобнее "обычной" реляционной схемы.. Вопрос в производительности, да и вообще в удобстве работы с системой. У меня на столе лежит диск с Таминой, но может кто-то уже ревьюил? |
| ||
| а положи куданить посмотреть? или может URL есть. и вопрос - из каких соображений считается "очень привлекательным" ? у меня впечатление, что "нужные" в миру объекты на момент не стандартизованы. ну там бинарные, сжатие опять же. |
| ||
| http://www1.softwareag.com/Corporate/products/tamino/default.asp Вроде тут. {и вопрос - из каких соображений считается "очень привлекательным" ? у меня впечатление, что "нужные" в миру объекты на момент не стандартизованы. } Не понимаю, о какой ты говоришь стандартизации.. А привлекательно в плане разработки. Вообще процесс O/R Mapping - это определенные усилия в разработке. Естественно, просто взять объект и пихнуть его в БД - гораздо более привлекательно, нежели делать этот маппинг в реляционную структуру. А то, что СУБД позволяет потом делать запросы, критериями которых являются поля этих объектов - вообще замечательно. Кроме того, тут мы приходим к еще одной интересной штуке: возможности "безболезненного" изменения структуры объектов предметной области - эти изменения не будут "тянуть" за собой необходимости изменения структуры БД. Про бинарные и сжатие тоже не понял. Какое отношение это имеет к объектам в принципе? Объект "Юзер" не может быть бинарным или сжатым, это всего лишь способ его хранения - максимум.. Или ты что имел в виду? |
| ||
| Или ты что имел в виду? объекты реального мира и имел в виду. картинки, музыку, видео и т.п. потоки, словом всё, что живёт в интернете. сжатие (упаковка), как я понимаю, на момент большая проблема, из-за огромных накладных расходов при обмене этим самым XML оно, сжатие, всем весьма требуется. и, как я слышал, с этими двумя эээ вопросами сейчас всё неоднозначно - стандарта нет, есть какие-то фирменные реализации. |
| ||
| спасибо за ссылку. через пару недель машинку соберу - попробую попробовать. не понимаю, в чем привлекательность пихать в БД? пихать вообще на задачу не похоже, как мне кажется. может где-то есть описание техник работы с данными? ну как это, к примеру, обстоит с реляционными - там б-деревья, bitmap-овые и т.п. индексы, и т.д. А то, что СУБД позволяет потом делать запросы ага, вот это самое! вроде как не было придумано ничего нового за последние лет 10, ну за исключение bitmap. или было? может есть описание "как"? |
| ||
| Видимо, я плохо объясняю :) В том, что СУБД позволяет делать запросы, действительно нового ничего нет. Но что я имел в виду. Есть объект реального мира. Скажем, это объект User, описывающий пользователя нашей системы. Для того, чтобы отмапить этот объект реального мира в теблицу данных нам нужно создать ее с соответствующими полями: имя, фамилия, адрес (кстати, объект адреса тоже может считаться отдельной сущностью), время регистрации, роль в системе. Таким образом, мы имеем объект предметной области , с которым и оперирует система. Он инкапсулирует в себе какую-то фуркциональность, нам сейчас не важно какую, но, например, операции "проверить валидность", "пересчитать количество средств на счете", что-то еще. Ну, работает это все на уровне бизнес-логики - и работает. Но необходимо еще сохранять всю эту информацию в базе данных, структуру которой я показал выше. В этом случае делается некий маппер, позволяющий "раскладывать" свойства объекта User в структуру БД (и обратно). Что же мы имем в случае, если БД у нас XML-нативна? Как мне видится, как минимум то, что мы избавлены от необходимости делать маппер. Мы просто берем объект User, сериализуем его в XML и "скармливаем" базе данных. Ну, и обратно, поскольку база XML-нативна, то мы можем сделать запрос в нее, сразу получив удовлетворяющие ему сериализованные объекты User. В принципе, идея та же, что и в реляционной БД, конечно, однако: 1) Мы избавлены от необходимости маппинга каждой сущности в поля базы данных. Работа с объектами любого типа становится однотипной: сериализация/десериализация, это реализуется 1 раз в 1 месте, а не для каждого типа отдельно. 2) Мы не связаны жестко схемой БД (хотя, как я понял, существует возможность "назначить" некоторые свойства обязательными, иными словами, документ Order в хранилище User'ов не влезет, и это правильно). При необходимости раасширить набор свойств сущности User мы просто делаем это (например, добавляя новое свойство "гражданство" или "фотография"), совершенно не заботясь о том, чтобы переделать маппер и структуру БД. 3) Мы получаем возможность хранить более-менее однотипные документы в одном хранилище и работать с ними _на уровне базы данных_ (не на уровне бизнес-логики) одинаково 4) Ну и наконец, в то время, как XML/XSLT является одним из самых простых и быстрых в реализации, но в то же время достаточно мощным способом отделения данных от представления, мы получаем не только такую замечательную возможность, как удобную реализацию MVC, но и прекрасную возможность трансформирования данных из одного формата в другую. Поясню: очень распространены приложения (особенно интернет-приложения), в которых предполагается обработка данных от большого количества компаний и предоставление данных им. Часто это страховые компании, банки и организации, дающие кредиты и т.д. Естественно, каждая из них имеет свой формат данных и желает получать обратную связь в известном ей формате. Естественно, само приложение хранит данные в единственно удобном ему формате (ведь по смыслу своему данные этих компаний если и отличаются, то не сильно). Соответственно, XML-база данных в перспективе может явиться хорошим решением в свете нежесткой спецификации "таблиц". Все же документы чем-то могут отличаться, особенно, когда для разных компаний необходимо хранить информацию, которая никак не обрабатывается приложением, но обязательно должна быть задействована при коммуникации: внутренние собственные идентификаторы данных, которые компании использут уже у себя и т.д. Соответственно, для добавления новой компании, достаточно (в первом приближении) сделать XSLT-документы, трансформирующие данные приложения в известный этой компании формат, и наоборот... Словом, полезностей можно увидеть кучу. Вопрос лишь в том, как именно это работает и с какой производительностью :) Ну, и учесть то, что MS SQL Server 2005 тоже умеет уже нативно хранить XML-документы, индексировать их, осуществлять индексный поиск по полям документа и т.д.. |
| ||
| ну т.е. как нет? выше, кажется, говорилось, что СУБД нативная. вот и интересовала логика. и, опять для примера - для реляционных эта логика широко описана. как и что делается. внутри. берем объект User, сериализуем его в XML зачем разбирать объект в XML? :) в чем будет выигрышь? если мы разбираем объект в структуру РБД у нас десятилетия обыта и оптимизации механизмов работы с данными. что значит "сразу получив" пока непонятно. а "сериализованные объекты user" это хмл-текст, вот это: <?xml version="1.0"?> <ROWSET> <ROW> <USERID>0</USERID> <USERNAME>myUser</USERNAME> <GID>0</GID> <STATUS>1</STATUS> <ACCESSLEVEL>1</ACCESSLEVEL> <ISUSER>0</ISUSER> </ROW> <ROW> ... это можно дёшево получить десятком разных способов. что тут должно цеплять за душу? я что-то пока не уловил мысли (полагаю, что для этого нужно книжку с ответами на мой вопрос "как") Мы избавлены от необходимости маппинга каждой сущности в поля базы данных я, честно говоря, пока в этом не уверен. просто не в курсе успехов в создании механизмов работы с данными в этой области (поэтому и спрашиваю "как"). кроме вопросов работы с данными висят вопросы хранения (объёмов) и пересылки, в частности. а не для каждого типа отдельно это как понимать? атрибутов не будет? Мы не связаны жестко схемой БД пока вопрос, как я понимаю, всёже открыт? возможно оно где-то как-то так и выглядит. а что внутри неизвестно. При необходимости раасширить и? вот добавили атрибут, все xml'и в базе поменялись? как? резервировалось место? сколько? переписалось всё в другое место? куда? как быстро? Мы получаем возможность хранить более-менее однотипные это опять надо понимать так, что атрибутов не будет? 4 это уже есть несколько лет, и xslt-репозиторий, и пара-тройка коммерческих продуктов. книжку надо, с теорией (мне). есть такие? |
| ||
| По поводу этого сообщения: Саш, прочитай полностью, а потом отвечай по пунктам ;) Ибо мне непонятно получать вопрос типа: "что значит "сразу получив" пока непонятно" В то время, как ниже того, где ты это встретил, я говорил о десериализации... Ответ на вопрос "как": очень легко написать функцию, сериализующую объект (практически) любого типа. Для того есть встроенные средства (и Java и .NET и другие платформы). В этом и выгода - в том, чтобы не писать маппинг для каждого типа объекта. {пока вопрос, как я понимаю, всёже открыт? возможно оно где-то как-то так и выглядит. а что внутри неизвестно.} Пожалуйста, поясни, что имеется в виду. {и? вот добавили атрибут, все xml'и в базе поменялись? как? резервировалось место? сколько? переписалось всё в другое место? куда? как быстро?} Да нет, XML-ки, которые там лежат без этого атрибута, так и будут там лежать, как я понимаю. В этом и плюс такой системы: мы можем хранить информацию, которая не является нужной приложению, но является необходимой для тех, кто пользуется этим приложением. Причем для объектов одного типа, но для разных, скажем, партнеров эта "добавка" может быть своей. Вопрос "как" это делается внутри меня мало волнует, в отличие от вопроса "как быстро" :) {это уже есть несколько лет, и xslt-репозиторий, и пара-тройка коммерческих продуктов} Так я и не говорил, что тут что-то новое принципиально... Существуют вообще объектные базы данных :) {книжку надо, с теорией (мне). есть такие?} Не знаю... |
| ||
| В то время, как ниже того, где ты это встретил, я говорил о десериализации... не вижу. а зачем может потребоваться уже разобранный и теперь нативно в нативной базе лежащий объект опять собирать? "как": мой вопрос "как?" не такой, как ты его понимаешь. не вижу почему вообще стоит обсуждать лёгкость написания функций и удобство программиста, когда инструмент для манипуляции данными (база). кстати ты и сам похоже интуитивно понимаешь что, в частности, скорость важна (а в "жизни" еще много чего). да и вообще гораздо интересней, как устроен поиск, какую аналитику можно считать, как связи между объектами поддерживаются и т.п. Пожалуйста, поясни, что имеется в виду так а что пояснять, устройство ящика знать интересно и только. так и будут там лежать ... объектов одного типа бывает такое? в какой-то момент не оказывается обязательного атрибута и всё продолжает жить? |
| ||
| { а зачем может потребоваться уже разобранный и теперь нативно в нативной базе лежащий объект опять собирать?} Так чтобы в дальнейшем оперировать им. {не вижу почему вообще стоит обсуждать лёгкость написания функций и удобство программиста, когда инструмент для манипуляции данными (база). } Потому что об удобстве в этом разрезе я и говорил. Удобство работы с БД тесно связано с затратами по расширению/изменению приложения, а это очень важный фактор. Еще об удобстве расширения и сохранения целостности данных. Еще потому, что уроверь бизнес-логики в базу не запихаешь (во всяком случае это было бы сумасшествием). Да и вообще БД существует в контексте приложения. {да и вообще гораздо интересней, как устроен поиск, какую аналитику можно считать, как связи между объектами поддерживаются и т.п.} Это да, потому и спросил. {бывает такое? в какой-то момент не оказывается обязательного атрибута и всё продолжает жить? } Да, конечно. Существует такое понятие, как "значение по умолчанию". Например, если у юзера нет атрибута "роль" его, вероятрно, можно считать принадлежащем роли "гость". Кроме того, я ведь уже говорил о том, что там вроде бы указано, что можно назначить в базе обязательные элементы, которые всегда должны быть и отсутствие которых будет приводить к ошибке.. Вот, говорю снова. То есть, задав в базе наличие обязательных элементов и атрибутов объекта (взять с уровня бизнес-логики) нам будет позволено сохранять в БД (и оперировать) плюс еще какую-то дополнительную, зависимую от случая информацию без изменения структуры БД. |
| ||
| прочитал и про MS SQL Server 2005 впечатление такое, что всё еще хуже, чем на самом деле ;-) "Вопрос лишь в том, как именно это работает" дык да, это _именно_ и интересно:) |
| ||
| А что с MS SQL 2005? В плане работы с XML? Мне еще предстоит с этим покопаться :) |
| ||
| не знаю и видимо не суждено узнать ;-) лишь _читал_ об этом (где-то в статьях на рсдн) на мой взгляд всё там странно ;) |
| ||
| почитал я их FAQ... и как-то не в восторге. фирмА, сабсеты от стандарта, ранние релизы, фултекстный поиск (как мне кажется успехов там нет и не предвидится), что-то там онли4 уиндоуз, "да, вы знаете, базы, они вообще большие", картиночки ссылками, какой-то акцент на "можем правильные" странный (мне как-то всё невалидные данные там мерещатся, либо деградация скорости при валидации). нет, не в восторге. думаю "чудо" не вызрело исчо. буду ждать твоих тестов ;-) |
Отправил