Каморка

george писал(а):InterSystems- не стартап далеко, ей уже 25 лет, и сейчас она наиболее динамично развивается, по сравнению с другими производителями БД.

сколько из этих 25 лет они делают базу?

george писал(а):SQL в Cache' тоже есть, проблем не вижу (про реляционные запросы). Вообще реляционную парадигму тоже можно реализовать в Cache', поскольку реляционная модель является частным случаем объектной.

правильно, танком гвозди тоже можно забивать.

вопрос только зачем.

george писал(а):Насчет дешивизны SQL Server или Oracle (это я к вопросу инструмента) по сравнению с Cache' вопрос спорный... Конечно, у них есть декларативные т.н. "процессорные лицензии", мол, покупая условно говоря за 25К лицензию, вы подключаете неограниченное число пользователей. А вот сколько реально они "вытянут"?

как построишь столько и вытянут.

у меня скл сервер несколько десятков тысяч тащил в прошлой лавке

george писал(а):Очень сильно зависит... У ИС же есть достаточно гибкая лицензионная политика, часто практически "договорные" цены.
Вот про специалистов да, согласен, что пока их немного. Но ведь и изучить эту БД не так уж сложно, зная основные принципы ООП (а это знают все), SQL и HTML. Знаю примеры освоения "с нуля" и написания достаточно больших систем за 5-6 человеко-месяцев.

основные принципы ООП знают _далеко_ не все. правильно их использовать умеют немногие от этих _далеко_ не всех программистов. Я за свою жизнь видел всего несколько человек способных грамотно построить фреймворк с использованием ОО методологии. под этим понимается несколько тысяч классов, интерфейсов и прочей бадяги. нарисовать класс с интерфейсом и имплементацией могут многие... только это не значит что они знают как это _правильно_ сделать.

george писал(а):ЗЫ Папа Карло, вот мне стало интересно, как не плодить поля или таблицы? Поделись, а?

на вскидку (один из возможных вариантов):

PRODUCTS
product_id <PK>
product_name

PARAMETERS
parameter_id <PK>
parameter_name

PRODUCT_PARAMETERS
product_id <PK,FK>
parameter_id <PK,FK>
value

PK = primary key
FK = foreign key

это один из возможных подходов. возможны вариации этой схемы в зависимости от требований.

папа Карло писал(а): сколько из этих 25 лет они делают базу?

А все 25 лет и делают, на самом деле. Компания специализируется исключительно на разработке БД. Раньше они делали MUMPS (слыхал про такую БД?), называлось это Intersystems Standart MUMPS (ISM), потом в 90-е годы они съели всех производителей MUMPS (или просто M) - Data Tree, Micronetics, объединила все лучшие идеи и разработчиков, очень удачно наложила на иерархическое ядро базы объекты, и вышла с новым продуктом в 97-м году - Cache' 2. Сейчас уже идет Cache' 5.

папа Карло писал(а):правильно, танком гвозди тоже можно забивать. вопрос только зачем.

сильное утверждение

вопрос в разности стоимости молотка и танка и РСУБД и Cache'. Как бы танк дешевле молотка не вышел

папа Карло писал(а): как построишь столько и вытянут. у меня скл сервер несколько десятков тысяч тащил в прошлой лавке

не спорю, что от профессионализма реализации конкретной задачи зависит 90% эффективности работы системы. Но вот в общем и целом Cache' оказывается попроизводительнее на практике (см. опять-таки отчеты)

папа Карло писал(а):основные принципы ООП знают _далеко_ не все. правильно их использовать умеют немногие от этих _далеко_ не всех программистов. Я за свою жизнь видел всего несколько человек способных грамотно построить фреймворк с использованием ОО методологии. под этим понимается несколько тысяч классов, интерфейсов и прочей бадяги. нарисовать класс с интерфейсом и имплементацией могут многие... только это не значит что они знают как это _правильно_ сделать.

ну, для этого и есть Папы Карло?

папа Карло писал(а):на вскидку (один из возможных вариантов):
.........

если я правильно понял, то на основе таблиц искусственно строится иерархия. А зачем прикладными средствами делать то, что в других БД заложено на уровне ядра базы? Потеря производительности системы- раз, потеря производительности труда программиста - два, трудности с эксплуатацией (внесение изменений в код) - три.

Ай, напрасно я затеял эту дискуссию, наверное... Папа Карло, я тебе в приват щас отпишу.

george писал(а):А все 25 лет и делают..... [skiped] .....вышла с новым продуктом в 97-м году - Cache' 2. Сейчас уже идет Cache' 5.

какой процент рынка датабаз у них? и скажем у сайбеза?

george писал(а):
папа Карло писал(а):правильно, танком гвозди тоже можно забивать. вопрос только зачем.
сильное утверждение вопрос в разности стоимости молотка и танка и РСУБД и Cache'. Как бы танк дешевле молотка не вышел

может быть дешевле, только не каждый танк въедет на второй этаж по деревянному каркасу.

george писал(а):не спорю, что от профессионализма реализации конкретной задачи зависит 90% эффективности работы системы. Но вот в общем и целом Cache' оказывается попроизводительнее на практике (см. опять-таки отчеты

отчеты подготовленные кем, извините?

урл (только не урл сайта разработчика или консалтинговой компании в области кэш, нам чего-нить независимого)? и самое главное на каких задачах? я уже говорил что требования могут быть покрыты в одном случае ОО моделью в другом реляционной лучше.

george писал(а):
папа Карло писал(а):основные принципы ООП знают _далеко_ не все. правильно их использовать умеют немногие от этих _далеко_ не всех программистов. Я за свою жизнь видел всего несколько человек способных грамотно построить фреймворк с использованием ОО методологии. под этим понимается несколько тысяч классов, интерфейсов и прочей бадяги. нарисовать класс с интерфейсом и имплементацией могут многие... только это не значит что они знают как это _правильно_ сделать.
ну, для этого и есть Папы Карло?

я знаю ООАД, но не могу его делать так-же хорошо как люди которых я знаю. я знаю что с данными и протоколами делать.

george писал(а):
папа Карло писал(а):на вскидку (один из возможных вариантов):
.........
если я правильно понял, то на основе таблиц искусственно строится иерархия. А зачем прикладными средствами делать то, что в других БД заложено на уровне ядра базы? Потеря производительности системы- раз, потеря производительности труда программиста - два, трудности с эксплуатацией (внесение изменений в код) - три.

Ай, напрасно я затеял эту дискуссию, наверное... Папа Карло, я тебе в приват щас отпишу.

дядька, да ты чего?

это же обычное отношение многие ко многим между параметрами и продуктами. обычная нормализованая модель.

операция там ну абсолютно за уши не притянуты:

дай мне все параметры продукта:

Код: Выделить всё

select parameter_id, value from PRODUCT_PARAMETERS where product_id = 10

дай мне все мячики, которые имеют красную полосу:

Код: Выделить всё

select product_id from PRODUCT_PARAMETERS where parameter_id = 20 and value = 'red'

Руки чешутся, но отвечать не буду, а то точно будет реклама одна...

george писал(а):Руки чешутся, но отвечать не буду, а то точно будет реклама одна...

ссылка на независимое тестирование есть?

папа Карло писал(а):ссылка на независимое тестирование есть?

РАО ЕС России подойдет? http://www.kavkaz.elektra.ru/cgi-bin/4main.cgi?id=5 новости за 29-30 апреля

george писал(а):
папа Карло писал(а):ссылка на независимое тестирование есть?
РАО ЕС России подойдет? http://www.kavkaz.elektra.ru/cgi-bin/4main.cgi?id=5 новости за 29-30 апреля

посмотрел краем глаза:

вопросы:

1. почему не оспользовался OCI?
2. кто ставил и настраивал оракл? как именно он был установлен?
3. по размеру задач скажу что там оракл нафиг не нужен. это монстр который используется на огромных базах. там надо было использовать что-то маленькое типа сайбейза или мс скл сервера.
4. кикие харды и контролеры использовались в машинах?

Кстати, вот и про сайбейз: http://www.osp.ru/cw/1998/35/22_print.htm
А с тех пор ядро базы стало еще в несколько рах быстрее! А по объему продаж сайбейз уже обогнали. Рынок еще у них больше, наверное, но по объему продаж они уже сзади.
Ну все, теперь точно умолкаю!!!!

прочитал тесты внимательно.... создалось впечатление что люди к тестированию подходили с точки зрения доказать что кеш лучше, а не чесно сравнить.

там скорее всего кто-то кого-то подмазал

не описаны юз кейзы. из того что увидел в докладах выступает какая-то кривизна дизайна.... короче грустно, товарищи.

объема у задач нет... 1,000,000 записей это детский сад для оракла и скл сервера.... совсем детский сад.... сравнения на таких маленьких объемах производить нет смысла ибо они не дла таких баз. 1,000,000 будет хорошо работать даже на аксессе.

покажи мне миллиард или два записей в одной таблице построеных на кеше.

george писал(а):Кстати, вот и про сайбейз: http://www.osp.ru/cw/1998/35/22_print.htm
А с тех пор ядро базы стало еще в несколько рах быстрее! А по объему продаж сайбейз уже обогнали. Рынок еще у них больше, наверное, но по объему продаж они уже сзади.
Ну все, теперь точно умолкаю!!!!

Sybase 11?

дык это вчерашний день

люблю пацанов сваливающих проблемы дизайна на плохое железо и софт.

Мои 5 копеек. Как бы, мимоходом.
(Прошу не ругаться модно, мол, шёл - и иди)

Меня ничуть не заинтересовали существующие реализации этого счастя, тем более, что есть и другие. Однако у меня, Российского неуча из Жопинск-Урипинска возникли вопросики к настоящим знатокам дела.
При этом обращаюсь с просьбой подсказать и научить, главным образом к автором сего могутного и плодотворного топика.

1) Что есть OODB? Подозреваю, что ЭТО позволяет моделировать объектное поведение сущностей. Но если мы говорим объектное поведение, то надо б указать критерии, которые позволяет
определить эту категорию и в контексте топика.

Ярые сторонники COM, говорят, что только COM является по-настоящему объектной моделью.
Ярые сторонники объктного представления принятого, например, в С++ говорят, что только такая модель является по-настоящему объектной (в отличие от COM).

Таким образом, несмотря на то, что оба подхода не противоречат парадигмам ООП - это разное. Функционал, возможности для прикладного программиста там разные. Смех. ООП и там, и там. Но это разное ООП.

Тогда естественно возникает вопрос - а какие постулаты ООП (наиболее признанные) имеют имплементэйшн в тех моделях OODB, о которых Вы говорите? И какой имплементэйшн?

Наследование? Чего? Структуры данных? Не смешите. Всё это делалось давно и делается сейчас в очень даже не сложных надстройках для обычных RDBMS. Где-то хуже, где-то лучше.

Инкапсуляция? Чего? Хранимых процедур, или их аналогов? Не смешите. То поведение сущностей, которое в реальных ситуациях необходимо моделировать гоооораздо сложнее, чем применение триггера или хранимой процедуры "по-наследству".

2) Почему Вы считаете, что невозможно моделировать, и моделировать эффективно, объектное поведение сущностей, используя специальные надстройки в обычных RDBMS?
Здесь на форуме в других топиках обсуждалась вскользь эта тема. Если моделировать так, как там, то я тоже считаю, что не получится. Но может надо просто по-другому? Т.е. нужны аргументы, что мол невозможно реализовать полнценную объектную модель на платформе RDBMS, поскольку ....... Ну, и здесь Вы, красавцы, разворачиваете крылья, и режете матку-правду с использованием технических терминов, указаний на результаты соответствующих исследований, тех. отчётов, статей и т.д.

ПС. Фамилия моя начинается на букву "г". Так что не серчайте.

что не надо доказывать людям, которые в чем-то абсолютно уверены, что они неправы. Вот и не буду, хотя имею свои соображения по каждому пункту высказанного.
Папа Карло, лови приват опять.

что не надо доказывать людям, которые в чем-то абсолютно уверены, что они неправы. Вот и не буду, хотя имею свои соображения по каждому пункту высказанного.
Папа Карло, лови приват опять.

Ну, да. Хороший ответ. По-нашему. По-совковски.

ок. Я прошу разрешения у папы Карло на ответ. Мона, или это будет рекламой?

ты пиши, пиши, только с технической стороны. если чего "пофиксим" тебя, какая разница.

Каморка

Объектные БД

Говорил мне один умный человек...