Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 17 18 19 20 21 [22] 23 24 25 26 .. 39   вперед  Ctrl
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Чернышев Андрей Леонидович
Спасибо, за краткую подсказку, ASCRUS, но я осознанно пишу идентификаторы. Это повышает самодисциплину. Вы можете предложить разработчикам: "пометили" идентификатор в тексте, и щелкнули мышкой. Кроме того, "эта БД" концептуально слабо проработана. Нет (возможно, что я просто не нашел ?) концепции "диалога" и других полезных вещей.

Андрей Леонидович, то, что Вы повышаете свою самодисциплину - это конечно достойно и похвально. Однако, если почитать правила SQL.RU:
Правила
Рекомендуется:
  • При цитировании информации из другого источника, указывать на него ссылку. При ссылке (в т.ч. на другой топик этого же форума) создавайте линк, оформленный тегом url.
  • 30 янв 06, 06:46    [2299013]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    Павел Воронцов
    Member

    Откуда: Новосибирск
    Сообщений: 2402
    Блог
    Чернышев Андрей Леонидович
    Нет, Павел Воронцов, я не требую от Вас "технических подробностей". Мы обсуждаем вполне конкретный теоретический вопрос. Что значит "скорей всего" (ведь оба Ваших "запроса" делают одно и то же) ? Ведь Вы уже не раз вычисляли "итоги" вместе с отбором кортежей по условиям в различных приложениях ?
    Меня тоже не смущает "не соответсвие схеме БД" вычисленной суммы. Ничуть. Читайте 2255042 и 2255811, и начнем сначала.
    Ваше желание поучаствовать в разработке объектного навигатора в Новосибирске я одобряю, и никак этому не припятствую. Что касается моих консультаций, то я работаю в конкретной организации, и настроен весьма патриотично. Так что обращайтесь к моему руководству. Здесь я представляю ТОЛЬКО СЕБЯ, и обсуждаю, в основном, именно теоретические вопросы.
    Капец. Я устал с этим разговаривать. Перехожу в зрительный зал.
    30 янв 06, 07:19    [2299026]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    mir
    Member

    Откуда: Томск
    Сообщений: 1027
    2 ASCRUS
    По поводу вставки ссылок вместо кодов. Уважаемый, разве вы забыли, что я "добивался" этой элементарной вещи от ЧАЛ еще с 8-й по 11-ю страницу данной темы:
    Я
    Бредовый ответ ЧАЛа
    Я в недоумении
    Еще более бредовый ответ
    Уставший я
    Оказывается, это ЧАЛ себе так "самодисциплину" развивает. Правда почему-то за наш счет.
    30 янв 06, 07:59    [2299064]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    mir
    2 ASCRUS
    По поводу вставки ссылок вместо кодов. Уважаемый, разве вы забыли, что я "добивался" этой элементарной вещи от ЧАЛ еще с 8-й по 11-ю страницу.

    Конечно не забыл :)
    30 янв 06, 08:23    [2299089]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    mir
    Member

    Откуда: Томск
    Сообщений: 1027
    shuklin
    …Слевдовательно есть множество всех колонок РБД. И есть множество всех возможных значений всех колонок в РБД. И возможно построить декартовое произведение множества колонок на множество значений. Очевидно, что каждая конкретная строка таблицы есть подмножество такого произведения, что согласно определению есть отношение ))))))))
    Идея понятна: «множество всех возможных значений» действительно существует и в теории называется «универсум». Я и не говорил, что это невозможно. Напомню, я сказал, что ваше определение скверное. По крайней мере оно существенно хуже определений РМД. Хотя бы потому, что в РМД поддерживается явная диверсификация типов. Вы используете универсум, следовательно типизации нет. К примеру, раз явно не заданы типы «элементов строк» (имеются в виду ваши «строки»), система не способна выявлять ошибки несоответствия типов. В «колонку» ФАМИЛИЯ можно занести дату, в «колонку» ВЕС — строку «Привет» и т.д.
    Раз нет типов — нет и операций, связанных с типами.
    Далее, раз ваша «строка» — это некое подмножество произведения множества «имен колонок» на универсум, то каждая строка может иметь по несколько вхождений одной и той же колонки с разными значениями, к примеру, (ВЕС, 5) и (ВЕС, 10). С точки зрения вашего определения это абсолютно корректно. Более того, каждая ваша строка может иметь произвольное количество элементов, и с точки зрения вашего определения это тоже абсолютно корректно.
    Определения в РМД гораздо лучше, потому что они гораздо строже. Как известно, знания — это правила, а правила — это ограничения. То есть мы вкладываем в систему знания, задавая ограничения. Система, в которой вообще не заданы ограничения, не «знает» вообще ничего. И управлять ничем не может. Поэтому из вашей СУБД/ СУБЗ букву «У» можно смело исключать.

    shuklin
    а тип - VARIANT я уже писал вам ранее, или System.Object если хотите )))) впрочем, в ТМ нет типов у элементов - там элемент может иметь любой тип, тоесть помещать в одно множество строки, числа, картинки, другие множества и любую ерунду допустимо, что эквивалентно типам OLE-VARIANT/.NET-Object.
    Не питайте иллюзий, значение «любого» типа в VARIANT не поместишь. Только предопределенный набор типов. А бывают еще типы, определяемые пользователем, то есть не известные системе заранее. И VARIANT здесь не спасет. А на практике использование VARIANT’ов крайне не поощряется, так как производительность работы с ними низка, а возможность сделать ошибку — крайне высока. Но к главной теме обсуждения это все мало отношения имеет.
    30 янв 06, 09:02    [2299165]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    CesaTheGuest
    Guest
    Безмерно хочется поддержать такую занимательную беседу. Итак, господин ASCRUS, надыбал преинтереснейший докУмент,
    вот он. Я разумеется не высокого полета мысли теоретик, но осмелюсь предложить некий анализ данной статье.
    Может кому время сэкономлю для более глубоких изысканий. Тем не менее рекомендую внимательно прочитать сей труд, очень поучительно. Думаю чем моложе специалист, тем интереснее.

    Итак несколько цитат:
    «В частности, СУБД Paradox, которая в течение вот уже трех лет считается лучшей реляционной системой для ПК, оказалась совершенно непригодной для наших целей из-за неудобной организации данных и, самое главное, из-за самой реляционной модели, которую давно пора признать устаревшей.»
    Напомню, статья 94 года. Стало быть мировая общественность и многие участники этого форума заблуждаются уже 12 лет. Смотрим на рынок… И сколько нереляционных СУБД на вершине продаж, производительности?

    Следующая:
    «По убеждению авторов, современные модели данных и соответствующие оболочки выведут М на новый качественный уровень и повысят ее конкурентоспособность в сфере проектирования прикладных систем.»
    И где эта система М, может мы и в Мухосранске живем, но слышать-то про мегаперспективную разработку мы должны были, SQL же до нас как-то докатился.

    «При проектировании и эксплуатации прикладных систем в реляционной среде и разработчикам, и пользователям приходится держать в голове перечень полей различных отношений (таблиц) для организации связей между таблицами. Иначе говоря, реляционная модель плохо поддерживает семантику данных. Кроме того, при идентификации объектов и организации связей возникают неудобства с внешними и составными первичными ключами.»
    Согласно ЧАЛ, его системой пользуются мегаюзеры, которые составляют по 40 запросов в день. Однако, у нас смертных, действительно, разработчику приходится помнить уйму таблиц и связей, такова жизнь. Кстати, по-моему, очень тяжело разрабатывать систему, если не знать что в ней. Но вот с пользователями у авторов неувязочка, они (юзеры) конечно таблицу в состоянии представить, но вот понятие связь думаю им недоступно в принципе. Поэтому они видят только накладные, ордеры и пр. Неудобств с ключами я как-то не примечаю никаких, без составных люди тоже легко обходятся.

    «При этом всякая связь в ООМД автоматически является двусторонней - в отличие от ER-модели, где потребовалось бы организовать две разные связи и, соответственно, создать для их описания два отношения в смысле реляционной модели.»
    Объясните кто-нить, какие две разные связи и какие два отношения на пальцах, не пойму я.

    «Связь может иметь свои характеристики: скажем, характеристики “позиция” (т. е. позиция детали на чертеже изделия) и “количество” (количество деталей в изделии) относятся не к изделию и не к детали, а к конкретной связи между ними. Естественно, между двумя объектами разрешается установить несколько связей. Например, “оснастка” “содержит” “детали” и “оснастка” “служит для изготовления” “детали”. Или: “читатель” “читает” “книги” и “читатель” “мечтает прочитать” “книги”»
    Связь с характеристиками просто меняется на отношения и простые связи, не вижу я в том проблем.
    «Простая реализация такой технологии возможна благодаря тому, что каждому экземпляру объекта поставлено в соответствие уникальное значение некоторой автоматически поддерживаемой ключевой характеристики (идентификатора). К такому способу представления данных пришел, в конце концов, и сам автор реляционной модели [1].»
    Суррогатный ключ решает все проблемы.

    Далее реклама продукта Inform-X, но финал порадовал, как вам перл
    «В базе данных этой системы 45 объектов и 206 связей. Если учесть еще и тот факт, что многие объекты имеют характеристики-наборы, можно с уверенностью предсказать, что при создании аналогичной системы в среде реляционной СУБД число таблиц превысило бы 500»
    Интересно как по мнению авторов, из 251 различной «сущности» получить 500 таблиц. Я так понимаю, надо сюда приплюсовать «Характерестики –наборы», так их можно вообще в одну таблицу свести. По мнению авторов сложность системы определяется количеством таблиц, мягко говоря странный вывод, у меня небольшой опыт, но берусь утверждать что это сомнительно.

    Вывод:
    С глубины моего невежества данная статья ни о чем, авторы ошиблись в своем прогнозе. Апеллировать к ней бесполезно.

    Кстати прочитав я понял, что есть этот самый объектный навигатор. Это средство просмотра схемы/содержания БД. Судя по всему он часть системы, что вроде Enterprise Manager (пример не совсем удачный). Создавая схему вы как-бы создаете и интерфейс, поэтому ув. ASCRUS, вам никогда не предоставят никакого кода, пока требуемые результаты укладываются в схему. Но остается проблема сложных отчетов. Согласно моим представлениям, то что Вы или я делаете запросами и процедурами там достигается наращиванием схемы. Если это все так, то Андрей Леонидович будет отбиваться очень долго. Остается вопрос в трудозатратах на наращивание схемы, какие они?
    Однако, я пробую по-другому. Внимание вопрос, что я должен заслать в систему если я хочу получить данные минуя интерфейс. Ведь если там нет ЯМД (сомнительно), то ЯОД там должен быть по определению. Андрей Леонидович поделитесь мудростью.
    30 янв 06, 10:43    [2299534]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    U-gene
    Member

    Откуда: Москва. Россия
    Сообщений: 1576
    2 ЧАЛ

    ....при желании разрешил бы пользоваться этим "запросом" конкретным своим коллегам. И далее по Вашему тексту. Кроме того, позаботится нужно и о том, чтобы пользователь мог бы сам вводить (динамически), например, >50 вместо >100, перед запуском "запроса", ну еще кое о чем....

    1)А что, это по Вашему проблема?
    2)Какое отношение это все имеет к РМД???

    То есть Вы начинаете понимать, что в подавляющем большинстве "случаев" пользователь объектного навигатора будет обходиться без программистов
    Опять крутите, ЧАЛ? поскольку объектный навигатор является Вашей собственной выдумкой и Вы до сих пор так и не обяснили
    1)как эта штука работает (а фантазию напрягать не хочу),...
    2)какое она отношение имеет к Вашим многочисленным самым общим теориям и чиста объектным моделям,...
    то я по прожнему ничего, касающегося, её не понимаю.Даже понимать не хочу. Потому что...


    U-gene
    ЧАЛ, скажите просто так, безотносительно ко всем прошлым спорам, множество {1, 2, 3, 4, 5} упорялочено? "ДА" или "НЕТ"?

    ...Тем не менее: взяв "исходные" пять чисел {3,2,5,1,4}, Вы упорядочили их по возрастанию: {1,2,3,4,5}. Я правильно понял "просто так, безотносительно ко всем прошлым спорам" ?
    Итак, ЧАЛ, значит Вы все же не можете сказать, упорядочено ли множество {1,2,3,4,5}, хотя в вопросе есть вся необходимая информация, для того, что бы дать простой ответ "ДА" или "НЕТ". На этот вопрос ответи любой студент, после второй лекции по ТМ. Поэтому, теоретик Вы наш общевеликий, перестаньте поучать других. А, судя по тому, что Вы считаете, что ">50" и ">100" или разрешения на доступ к таблицам и видам есть вопрос, Вы дейтсвительно, мягко выражаясь, далеки от сегодняшенго дня и в прикладном плане. То есть исходя из Ваших ответов (когда это не бла-бла-бла о принципиально-концептуальных недостатках РМД) картина о Вашем уровне знаний и умений складывается нерадостная. Не думаю, ЧАЛ, что Вы можете сообщить что-то полезное, как бы Вы не дулись. Продложайте упорядочивать шары в мешочках.
    30 янв 06, 11:05    [2299677]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    ggv
    Member

    Откуда:
    Сообщений: 1810
    CesaTheGuest - в том то и дело, что в этих "замечательных" базах, которыми занимается псевдо-ученый ЧАЛ, данные НЕ ОТДЕЛЕНЫ от приложений, в отличие от RDBMS, где данные таки отделены от приложений, и есть стандартный API доступа к данным из разных приложений, что гарантирует доступ к данным из любых приложений. А в случае до-реляционных баз данных придется такой API создавать самим.

    mir привел замечательное сравнение системы ЧАЛа и реляционной системы, которое прошло без внимания - простота vs сложность, и прочее. Интересное сравнение, и напоминает победу Кодда в нашумевшем диспуте.
    А вообще-то интересно - ЧАЛ предлагает предусмотреть все возможные значения и запросы, которые могут понадобытся пользоватиелям, заранее на этапе моделирования. Этот как же распухнет объем данных, из-за этих заранее вычисленных значений....
    Опять же, ad-hoc запросы были есть и будут - бизнес поставит вопрос, и аналитик составит запрос на извлечение данных, нужных бизнесу.
    Хотя, с другой стороны, все коммерческие RDBMS позволяют перманентно сохранять заранее вычисленные агрегаты, но гораздо более элегантно - оптимизатор может сам принимать решение о использовании заранее вычисленных значений при обращении к основным данным, можно в любой момент создать/удалить эти заранее вычисленные значений, не влияя на сами данные. Никакой подобной гибкости системы, отстаиваемые ЧАЛом предложить не могут.
    Чессло, обидно за российскую науку, породившую такое кол-во лже-ученых (ну хорошо - не лже-ученых, а, ученых, страдающих фигней с точки зрения практики). У меня вот только большой вопрос по их финансированию. Я не против - пусть исследуют. Но только не за мой счет. Я налоги плачу исправно, и не малые. И у меня вопрос - ЧАЛ и shuklin занимаются исследованиями на деньги спонсоров? Бизнеса? Или таки государста (то есть и мои?)
    Мне бы хотелось, чтобы сии два толстлобых - пардон, высоколобых - мужа нашли себе спонсоров на свои изыскания, получили гранты, и так далее. Государство тоже может давать гранты, но ведь с 1994 г прошла уйма времени - гражданин ЧАЛ, И ХДЕ НАФИГАТОР, Я СПРАШИВАЮ??? ГДЕ ВЕЛИКОЛЕПНАЯ, ОБЕЩАННАЯ НАМ СИСТЕМА???
    Все, понимаешь, на устаревших RDBMS приходится делать.... Массонский заговро произведителей RDBMS, блин.

    Лично мне насрать (пардон) на навигацию, идентификацию, семантику, елси их отсутсвие позволяет строить быстрые, гибкие, и прочая, и прочая, коммерческие системы. То есть системы, решающие реальные практические проблемы. (хотя я лично предпочел бы говорить, что данные отделены от логики, семантика вынесена на уровень приложений, данные объектов декомпозируются, ну и далее по списку).
    Кстати, бизнесу тоже насрать (пардон второй раз) на эти понятия, им нужны ответы на их вопросы, и как можно быстрее. Бизнесу нужны данные, а не объекты. Еще ни один мой работодатель не предъявил мне претензий по поводу запроса нашей системы, который возвращает данные по партнерам, с агрегацией по IP адресам с агрегацией по временным промежуткам, и прочее, который написан с использованием некошерных операторов GROUP BY, ROLLUP, GROUP BY GROUPING SETS
    30 янв 06, 11:42    [2299881]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    ggv
    Member

    Откуда:
    Сообщений: 1810
    как говорит мой коллега тлудшлщм, при решении задачи доставить слона из Африки, сипоганивший кучу бумаги на никому не нужную (окромя мышей) диссертацию, ЧАЛ напишет
    - go to Танзания
    - if нет слона в Танзания, go to Конго
    - if нет слона в Кого, go to Кения
    - if нет слона в Кения, go to Ангола
    - if есть слон в Ангола - return слон.

    А пользователи (ДАЖЕ ПОЛЬЗОВАТЕЛИ, а не только программисты) устарелых RDBMS напишут -
    SELECT слон FROM Африка
    30 янв 06, 11:48    [2299910]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    mir
    Member

    Откуда: Томск
    Сообщений: 1027
    Чернышев Андрей Леонидович
    Но. Group by, как известно, не реляционная операция.
    Напомню, что реляционной является любая операция, которая имеет аргументом одно или несколько отношений и результатом отношение. Операция GROUP BY полностью удовлетворяет этим требованиям. В чем же по-вашему ее нереляционность?
    30 янв 06, 14:16    [2300884]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    ggv
    Member

    Откуда:
    Сообщений: 1810
    бл*, и это кандидат каких-то там наук -
    ЧАЛ
    как известно, не является реалиционной.
    точка с восклицательным знаком.
    Хде известно, Кому известно, кто в каких трудах, ничего! Известно!
    и скоко же этот клоун наших денег перевел??? Скоко деревьев загубил, ирод!!!!
    Другому раскраски надо для графа, блин, как говорится, нам бы ваши проблемы.
    Сходу даю проблемы, решения которых можно продать
    По прогнозу IDC к 2007 году объем voice over IP услуг возрастет в 27 раз по сравнению с прошлым годом. Amdoc, CBOSS и прочие кривые решения решения, основанные на технологиях конца 80х годов не справятся с таким объемом (ftp для биллинга как способ передачи информации, создание файлов нулевой длинны но с данными закодированными в имени файла, и прочее). Чаржить то клиентов надо как-то...
    Shuklin - чем не тема?? Обыследоваться можно, и выдать рынку решение. Токо без цветной муры, но производительное.
    Не нравится? Так вот - аналитики нащывают 2006 и следующий год годами слияний и поглощений в банковсом секторе в России. А у всех банков - свои системы. Зоопарк блин и никакой совместимости. А предложить решение по интеграции? Ведь ясно, что одномоментно унифицировать невозможно...
    Что, тоже скучно? Цветности мало? Нам денех нинадо, нам графы даффай (цветные) ??? Потому как СКорЛува тесная, давит? А оглянуться вокруг? По лабам разным - ну IBMовским, оракловым, мелкософтовским? У них же сайты есть. Чего их волнует, над чем работают?
    да зачем уж, мы без оглядок на аффторитеты, и упрекнуть не смей, типа, гения каждый обидеть может.
    Тьфу...
    30 янв 06, 14:58    [2301123]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    pavelvp
    Member

    Откуда:
    Сообщений: 673
    Чернышев Андрей Леонидович
    Мне категорически интересна "такая идея", pavelvp, хотя в Intersystems с "моими" "представлениями", думаю, знакомы, а С.Д.Кузнецов, думаю, знаком с общей теорией баз данных.
    Жду приглашения.
    Ну ни хрена себе! Он ждёт приглашения!!! Да кто Вы такой, чтобы ждать приглашения?! Его нужно заслужить!
    Кстати, pavelvp. Поскольку я уверен, что с приглашением меня на семинар у Вас ничего не получится, мое предложение остается в силе, и даже усиливается раз Вы проявили искренний интерес.
    Ну я просто фигею! Даже это сообщение Вы сумели переврать!
    Господа! Ну где я говорил о том, что я буду заниматься приглашением Андрея Леонидовича на конференцию???!!!
    Готов провести семинар лично с Вами (Вы ведь приедете в Москву на тот официальный семинар).
    Знаете что... Не хотите делать доклад - так и скажите. А если нет, то подготовьте презентацию и направьте её на citforum.ru.
    Приглашения он ждёт, блин.
    И еще. А почему бы shuklin'a тоже не пригласить сделать доклад о своей разработке на том официальном семинаре, если он, конечно, не против ?
    Если shuklin захочет - выступит.

    Приглашения он ждёт...
    30 янв 06, 15:10    [2301201]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    shuklin
    Member

    Откуда: Харьков
    Сообщений: 799
    Чернышев Андрей Леонидович
    То есть ни суть, ни направление "спора" пока непонятны.
    Это история с бородой. В старые времена, кода я был наивен, и думал, что комуто здесь будет интересно разобраться во внутренней архитектуре моего поделия попытался ее описать. Ну начал с того, что в Cerebrum отношением является объект что соответсвует отношению = строке таблицы в РБД. Народ впал в неистовство, ибо правильная вера определяет отношение как таблицу. Конструктивной дискуссии не вышло, вот опять тот же вопрос но слегка по другому поводу вылез. Суть спора - мое заявление, что в РБД отношением является строка таблицы, а не вся таблица.
    30 янв 06, 15:47    [2301481]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    shuklin
    Member

    Откуда: Харьков
    Сообщений: 799
    Чернышев Андрей Леонидович
    Пример связи 1:М для начала.

    Партнер --- Является контрагентом по/Заключен с ---> Договор

    ...

    1) как конкретно реализуются (и объявляются) ДВЕ "однонаправленные" связи в Cerebrum;
    Если я правильно понял постановку и учитвая, что связь заказана, как классическая 1:М то в Cerebrum это будет, со стороны договора к партнеру связь 1:1 (тоесть для одного договора может быть только один партнер) и со стороны партнера к договорам 1:М (коллекция) В партнере надо сделать коллекцию однонаправленных связей на договоры, а в договоре поле с одной однонаправленной связью на партнера.

    Чернышев Андрей Леонидович
    2) как конкретно осуществляется навигация (перебор; взятие следующего, предыдущего Договора, заключенного с конкретным Партнером, и одного конкретного Партнера, являющегося контрагентом по Договору), и индексация, например, по дате заключения договора (именно по привязанным договорам) ?

    В коллекциях связи не упорядочены, точнее порядок определяется внутренними деталями реализации и основываться на этом порядке я бы не рекомендовал, от версии к версии он может менятся (были прециденты). Перебор элементов в коллекции осуществляется с помощью итератора. Если нужно ввести порядок на договорах - то можно это сделать с помощью односвязного либо двусвязного списка. Индексация в текущей версии поддерживается только по указателям. Остальные типы (даты, строки, числа и т.п. не индексируются). Поиск нужно будет вести fullscan по коллекции (а не по всей БД).

    Чернышев Андрей Леонидович
    3) как конкретно хранится и предъявляется пользователям семантика связей ? [если навигацию с "помощью инстанциирования" еще можно как-то принять, то семантику как "окрашивание с помощью ID" пока трудно принять без дополнительных разъяснений].


    Так как каждый объект может иметь несколько связей с любым другим объектом, то каждый указатель имеет еще и "окраску". Например в предыдущем примере коллекция указателей от партнера к договорам окрашена в "Является контрагентом по" а указатель из договора к партнеру окрашен в "Заключен с". Тоесть у объекта партнер есть аттрибут "Является контрагентом по" содержащий коллекцию, а у объекта договор есть аттрибут содержащий ссылку "Заключен с". Технически как коллекции так и ссылки можно реализовать по разному, сути это не изменит, а вот на перформанс может повлиять оч. сильно.
    30 янв 06, 16:01    [2301587]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    shuklin
    Member

    Откуда: Харьков
    Сообщений: 799
    Критикан
    В общем Было бы интересно увидеть результаты тестирования вашей БД.
    Например скорость заливки, выборки, удаления, апдейта. Потом попытаемся их сравнить с аналогичными результатами какой нить из СУРБД.
    Тесты давайте хотя бы примитивные, главная-подчиненная. Допустим 200000 записей в главной таблице и пару миллионов в подчиненной. Колонок штуки по 4 в каждой таблице разного типа - целое, вещественное, строка. И время выполнения вышеуказанных операций над этими записями. С описанием железа ебстественно. Что то наподобии
    этого и последующих постов. Жду с нетерпением :-)


    Привет, сильный вопрос. Обещаю подготовить такие материалы. ASAP. Увы это не будет быстро.

    Ваша постановка несколько некорректна по отношению к моей БД - там нет именно таких понятий. Какой тест я могу сделать:

    Создать два класса - например Company & Employee с соответсвующими полями. в классе компани будет аттрибут - коллекция эмплоев этой компании и отдельный указатель на директора. В классе эмплоя - указатель на компанию, в которой он работает и на его начальника.

    Ну и как просили, 200000 компаний по 10 эмплоев.

    Самыми интересными будут тесты на создание и на фуллскан (как по компаниям так и по эмплоям - по компаниям построить дерево, по эмплоям - список эмплоев с именем директора и компании). Так как при прямой навигации, в таком сценарии на каждую компанию будет инстанциировано всего по 11 объектов.
    30 янв 06, 16:22    [2301786]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    shuklin
    Member

    Откуда: Харьков
    Сообщений: 799
    Критикан
    Хоть что нибудь.

    Хоть что нибудь есть в поставке, однако далеко от того что Вам интересно.
    Здесь можно прочесть перед тем как качать:

    http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx
    http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Objects-01.aspx

    Кстати, качать не много. Всего 750КБ (исходники + бинарники) отсюда
    http://contest2005.gotdotnet.ru/Request/Tools/UtilitiesLib/163171.aspx
    30 янв 06, 16:26    [2301830]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    shuklin
    Member

    Откуда: Харьков
    Сообщений: 799
    mir
    Идея понятна:

    Ну и великолепно. Я вам идею хотел донести, а не точное определение для учебника дать.

    mir
    К примеру, раз явно не заданы типы «элементов строк» (имеются в виду ваши «строки»), система не способна выявлять ошибки несоответствия типов. В «колонку» ФАМИЛИЯ можно занести дату, в «колонку» ВЕС — строку «Привет» и т.д.

    Мы о чем говорили, о РБД или о Cerebrum? Ваше высказывание по отношению к Cerebrum абсолютно верно. Да, типы не проверяются, да, в колонку "вес" можно вводить шо угодно, хоть "привет" )))

    mir
    Раз нет типов — нет и операций, связанных с типами.
    Да.
    mir
    Далее, раз ваша «строка» — это некое подмножество произведения множества «имен колонок» на универсум, то каждая строка может иметь по несколько вхождений одной и той же колонки с разными значениями, к примеру, (ВЕС, 5) и (ВЕС, 10). С точки зрения вашего определения это абсолютно корректно.
    Согласен, здесь прокол. Этого в Cerebrum низя - by design. Надо будет определение подточить )))

    mir
    Более того, каждая ваша строка может иметь произвольное количество элементов, и с точки зрения вашего определения это тоже абсолютно корректно.
    Да. Может.

    mir
    Определения в РМД гораздо лучше, потому что они гораздо строже.
    Они лучше для РБД а к Cerebrum они не имеют прямого отношения.

    mir
    Система, в которой вообще не заданы ограничения, не «знает» вообще ничего. И управлять ничем не может. Поэтому из вашей СУБД/ СУБЗ букву «У» можно смело исключать.

    А это уже вопрос точки зрения. Впрочем ограничения есть, но другие.

    mir
    Не питайте иллюзий, значение «любого» типа в VARIANT не поместишь.
    Зато в System.Object можно запихнуть, благодаря boxing.

    mir
    Но к главной теме обсуждения это все мало отношения имеет.
    Именно
    30 янв 06, 16:41    [2301975]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    mir
    Member

    Откуда: Томск
    Сообщений: 1027
    shuklin
    правильная вера определяет отношение как таблицу. Конструктивной дискуссии не вышло, вот опять тот же вопрос но слегка по другому поводу вылез. Суть спора - мое заявление, что в РБД отношением является строка таблицы, а не вся таблица.
    Который раз чисто технической вопрос, вопрос элементарных знаний г-н Шуклин переводит в плоскость веры ("Мне моя вера очень даже позволяет значения и переменные путать"Б (c) Шуклин). Тогда как речь идет просто о знании определения общепринятого термина. Надо открыть любую книжку по математике или по БД, или воспользоватьчся поиском в Интернет, чтобы просто найти определение. Но г-н Шуклин демонстрирует особенный вид невежества: агрессивное невежество. "Ах я по-вашему не то понимаю под этим словом, что весь мир? Да это на самом деле я один только и понимаю правильно, а все остальные -- нет". Короче, все идут не в ногу, один Шуклин в ногу.
    Вы, г-н Шуклин, точно форумы попутали. Вам надо, как вы сами признаете, по вопросам религии. А здесь знания котируются.
    30 янв 06, 16:46    [2302024]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    Ц4
    Guest
    [quot shuklin... Суть спора - мое заявление, что в РБД отношением является строка таблицы, а не вся таблица.[/quot]

    общепринятым "кортежом" никак не обойтись?
    30 янв 06, 16:49    [2302051]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    mir
    Member

    Откуда: Томск
    Сообщений: 1027
    shuklin
    mir
    Определения в РМД гораздо лучше, потому что они гораздо строже.
    Они лучше для РБД а к Cerebrum они не имеют прямого отношения.
    Пока что видно, что вы из своих "строк" таблицу составить не сможете, так как как каждая "строка" может иметь разное количество элементов, то есть вхождений "колонок" (только что выяснили).
    Тогда что вы в Cerebrum понимаете под "колонкой"? Под "таблицей"? Ведь вы эти термины выдрали из РБД, но как сами говорите, они к Cerebrum не имеют отношения. Тогда он должны значить что-то другое. Что же?
    30 янв 06, 16:55    [2302087]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    vadiminfo
    Member

    Откуда: Обнинск
    Сообщений: 4802
    shuklin

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


    Называть следующиий текст наивностью было слишком мягко:
    shuklin

    Суть спора - мое заявление, что в РБД отношением является строка таблицы, а не вся таблица.

    Это гораздо хуже.
    После этого врядли кто-то захочет разбираться в поделиях автора, как громко их не называй.
    Впрочем, не ясно, что вообще нашел автор в описании своего поделия интересным. Наехал на РБД, типа логика такая: РБД - фуфло, а на безрыбье что попало сгодится и даже Селебрум сойдет. Такая же логика у ЧАЛа, тока он хочет дореляционную ОМД протащить.Правда стал стыдливо заменять слово дореляционная на классическая.
    Но почему они не объединят усилия? Шаклин вроде готов (видно надеется что када они в двоем опрокинут РБД, он в лекую задавит якобы классическую ОМД - она и в правду лекая добыча для любой, даже самой корявой системы).
    Но ЧАЛ не хочет. Знает, что его ОМД совсем никому не конкурент.
    30 янв 06, 17:25    [2302260]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    shuklin
    Member

    Откуда: Харьков
    Сообщений: 799
    mir
    Тогда что вы в Cerebrum понимаете под "колонкой"? Под "таблицей"?
    Для тех кто в танке http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx
    30 янв 06, 17:47    [2302401]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    U-gene
    Member

    Откуда: Москва. Россия
    Сообщений: 1576
    Для тех, кто вне танка.... Что народ про это думает.
    30 янв 06, 18:17    [2302562]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    Чернышев Андрей Леонидович
    Guest
    После неимоверных глупостей и лжи в 2298960, приводится для чего-то (!?) повтор решения Павла Воронцова с union. В результате получаем "отношение" (имя ? схема ?), которое, как правильно заметил Павел Воронцов, можно только "предъявить пользователю как отчет". А без union никак нельзя было "предъявить" ?
    30 янв 06, 22:02    [2303089]     Ответить | Цитировать Сообщить модератору
     Re: SQL, есть ли выход из СКорЛупы?  [new]
    Чернышев Андрей Леонидович
    Guest
    Разочаровал Quadro. Чистый треп. Видимо понял, что еще рано высказываться по сложным вопросам теории БД.
    30 янв 06, 22:04    [2303092]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 17 18 19 20 21 [22] 23 24 25 26 .. 39   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить