Использование объектно-ориентированных БД при WEB-разработке
20/02/2004
Кто-нибудь обладает опытом и/или информацией, почему subj не используется при разрабоке интернет-магазинов, коропоративных порталов и т.д. и т.п? Не невыгодно, сложно, непонятно как или что?
21/02/2004
А какие преимущества вы видите в объектно-ориентированных БД для разработки ИМ ? Возможно, несколько эффективнее можно реализовать иерархические структуры, например каталог товаров. Остальное же, легко ложится на традиционные реляционные БД. На самом деле, здесь вопрос нужно ставить несколько иначе. Почему до сих пор веб-разработки массово не шагнули в сектор тяжелых, коммерческих СУБД. Ответ простой - все это находится пока лишь в зачаточной стадии. Что такое к примеру data mining знают очень немногие. Чтобы было понятнее, аналогия для текущего состояния рынка эл.коммерции с технич. точки зрения: Рижский рынок в Москве в начале перестройки. Но попробуйте сейчас приткнуть свою палатку рядом с каким-ть Рамстором - фиг получится.
24/02/2004
Мой опыт говорит, что при разработке более-менее сложного сайта любого типа, 80% времени и сил тратится как раз на организацю иерархических структур из таблиц реляционных БД.
Почему не используются "тяжелы коммерческие СУБД" вполне понятно.
Но, насколько я понимаю, объектно-ориентированные БД так или иначе создаются на основе реляционных СУБД, а, например, MySQL - вполне подходит к данной категории, хотя конечно, и в "укороченном" материале.
Почему не используются "тяжелы коммерческие СУБД" вполне понятно.
Но, насколько я понимаю, объектно-ориентированные БД так или иначе создаются на основе реляционных СУБД, а, например, MySQL - вполне подходит к данной категории, хотя конечно, и в "укороченном" материале.
24/02/2004
Я в MySQL не силен, но по-моему она явно не тянет на "объектно-ориентированную". Если не ошибаюсь в ней транзакции и то появились в последней версии. *Чисто* объектная СУБД - Cache, но на ней внедрений - кот наплакал. Реляционная + объектная-ориентированная - Оракл, но стоит дорого.
А что кроме каталога товаров необходимо реализовать в виде иерархической структуры применительно к ИМ? Какие типовые задачи?
А что кроме каталога товаров необходимо реализовать в виде иерархической структуры применительно к ИМ? Какие типовые задачи?
24/02/2004
Проблем никаких - магазины создаются. Просто поинтересуйтесь, сколько Вам будет стоить лицензия на подобный магазин...
25/02/2004
Да, все правильно, MySQL не тянет на объектно-ориентированную, но я говорил что почти всегда ООБД создаются НА ОСНОВЕ реляционных БД, с помощью различных надстроек. Вот для этой цели MySQL вполне подойдет.
Структура магазина:
- каталог
- группы
- товары
- пользователи
- оплаченные заказы
- отложенные заказы
- и т.д.
- корзины
- пользователь (владелец)
- позиция
- товар
Это так, упрощенная схема, обычно она несколько более сложная. И это не считая различных вспомогательных сервисов.
Структура магазина:
- каталог
- группы
- товары
- пользователи
- оплаченные заказы
- отложенные заказы
- и т.д.
- корзины
- пользователь (владелец)
- позиция
- товар
Это так, упрощенная схема, обычно она несколько более сложная. И это не считая различных вспомогательных сервисов.
26/02/2004
Эх дела
вспоминаю свою бурную молодость когда начальник нам трахал мозги с объектными СУБД :)
5 лет прошло, а воз оказывается и ныне там.
Вывод - значит эти субд мало кому нужны
вспоминаю свою бурную молодость когда начальник нам трахал мозги с объектными СУБД :)
5 лет прошло, а воз оказывается и ныне там.
Вывод - значит эти субд мало кому нужны
26/02/2004
ООБД - не создаються на базе РБД - потому что им нужен совсем другой подход по организации взаимодействия - а проблема их использования - в том - что нет удобного и унифицированого язика иерархических запросов - коим в РБД есть SQL
27/02/2004
Да потому, что просто нет в них потребности.
Структуры у нас, как правило простые, софт наполовину уже написанный.
Причем все условно бесплатное. Так зачем мне еще на ООБД заморачиваться?
Я один раз видел процесс перехода на ООБД, обошедшийся компании в 100К и от которого потом пришлось отказаться )) и уйти на MS SQL.
Структуры у нас, как правило простые, софт наполовину уже написанный.
Причем все условно бесплатное. Так зачем мне еще на ООБД заморачиваться?
Я один раз видел процесс перехода на ООБД, обошедшийся компании в 100К и от которого потом пришлось отказаться )) и уйти на MS SQL.
Форум закрыт. Написание сообщений ограничено