Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 31   вперед  Ctrl
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
shuklin
!
Чем раньше вы начнете работу над многопользовательской поддержкой
те раньше вы поймете несостоятельность вашей модели с точки зрения
транзакций по управлению ссылками.
Отсутствие констрентов позволит осознать это еще быстрее.


Откуда такая уверенность ? ))) Увидим. В текущее время у меня специфические приоритеты )))


дохтурскую степень выловить в мутной водичке ?
13 дек 06, 09:16    [3528113]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
shuklin
С тем что анархия должна быть в рамках, согласен без вопросов )))


анархия в рамках - это концептуально
13 дек 06, 09:18    [3528118]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)
А град с неба - недоработка Гидометцентра.
Слепую веру не победить ничем

СУБД - это природное явление ? Ну ну - "Слепую веру не победить ничем"
13 дек 06, 09:31    [3528176]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
СУБД - это природное явление ?


Да нет, СУБД конечно творение рук человеческих (и весьма потому несовершенное ), а вот ROWID - вполне себе природное и его свойства полностью вытекают из его определения, это физический адрес. И ни Oracle ни Господь Бог этого не изменят. Конечно они (Oracle с Господом) могут придумать что то новенькое (как в случае с индексацией IOT-ов), но это будет уже не ROWID, а ... скажем ... UROWID
13 дек 06, 10:23    [3528462]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)
Конечно они (Oracle с Господом) могут придумать что то новенькое (как в случае с индексацией IOT-ов), но это будет уже не ROWID, а ... скажем ... UROWID

Именно это я и имел ввиду.
13 дек 06, 10:37    [3528550]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Конечно они (Oracle с Господом) могут придумать что то новенькое (как в случае с индексацией IOT-ов), но это будет уже не ROWID, а ... скажем ... UROWID

Именно это я и имел ввиду.


Угумс, а теперь скажите, чем это будет отличаться от доступа по PK ???
13 дек 06, 11:00    [3528704]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Gluk (Kazan)


Угумс, а теперь скажите, чем это будет отличаться от доступа по PK ???



Я об этом спрашиваю на протяжении 16 страниц.
Пытаюсь доказательства приветсти.

Думаю ответа мы не получим.
13 дек 06, 11:10    [3528780]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
А вообще, я просто хотел попросить предоставить простой пример, где было бы видна необходимость звезды. Если это нельзя здесь без этого оператора, тогда необходимость доказана.
[...]
Проблема формулируется так. К какому-то имени применяется операция:
myName.doSomething();
Вопрос: эта операция применяется к ссылке хранящейся в myName, или объекту на который указывает myName? Вот возможные принципиальные решения:

Решение 1. Запрет на операции со ссылками (арифметика указателей и т.п.) Соответственно, все операции применяются к объектам (Ява и др. современные ООЯ).

Решение 2. Специальный маркер типа звезды. Есть звезда - объект. Нет звезды - ссылка.

Решение 3. Операторы в объектах и ссылках не пересекаются, а значит по имени всегда можно определить к кому применять операцию.

Решение 4 (концептно-ориентированный подход). Ссылка всегда перехватывает все запросы, т.е. формально все операции применяются к ссылке.
Логически эквивалентно Решение 1 (ссылка и объект неразделимы).
Александр Савинов
Далее она решает, что делать дальше, в частности, отправить его объекту. Здесь эта проблема явно формулируется и принципиально решается.
Для программирования этой логики понадобятся соответвующие выразительные возможности - Решение 2. Необходимость опреатора * доказана :)
13 дек 06, 11:30    [3528963]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Кстати, по поводу "точечной" JOIN-free нотации г-на Савинова, которая должна привести к сокращению размеров запросов со страниц до считанных строк. А давайте на гипотетическим примере посмотрим?

Чтобы не выдумывать, я взял модель БД в соседнем топике "Обеды сотрудников". Картинка там есть.

Напишем такой наипримитивнейший запрос. Вернуть (отсортированный по ФИО) список сотрудников, которые с начала 2006 года жрали борщ более 100 раз. Для каждого сотрудника вывести также сумму его затрат на этот борщ.

Я "набросал" гипотетический запрос на SQL:
SELECT FIO, SUM(cost*count) AS TotalSum
FROM
  employee NATURAL JOIN dinner NATURAL JOIN menu NATURAL JOIN dish
WHERE
  dinnerdate >= '01.01.2006' AND name = 'Борщ'
GROUP BY FIO
  HAVING COUNT(*) > 100
ORDER BY FIO

Хотелось бы увидеть такой же запрос в гипотетической нотации г-на Савинова. Чтобы тык-скыть заценить резкое уменьшение размера при как минимум сохранении той же понятности запроса.
13 дек 06, 12:11    [3529347]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Александр Савинов
okdoky
Можно заметить. Фактически в Zigzag отсутствуют имена отношений (таблиц). БД Zigzag это множество классов объектов произвольно связываемых между собой отношениями.
И все-таки, я где-то не догоняю….
Попробую очертить принципиальные особенности модели данных языка (точнее СУБД) Zigzag. Возможно, это снимет часть вопросов. По сути, отличия СУБД и соответствующих им моделей заключаются в подходах к описанию типа. Увы, здесь без терминологии не обойтись. Что такое тип? Мы долго спорили об этом с mir и частично с U-gene. Они по привычке (ссылаясь на литературу по РМД) вкладывают в понятие тип тоже, что и в домен, то есть просто множество значений. При этом не вдаваясь в детали, что тип может и должен иметь свое имя и свойства. Отличие терминологии ОМД проявляется в том, что под типом понимается объект «класс», который описывает не только поля, но и методы применимые к соответствующим ему объектам.

В последнее время под типом в РМД, все чаще, понимают именованное множество значений. Происходит прогресс. Но даже этого недостаточно. Я бы кратко охарактеризовал тип как множество определяемых значений. Определение типа, это не только задание ему имени, но и описание свойств. Реально, как в РМД, так и в ОМД, описание свойств типа сводится к перечислению типов свойств, то есть к описанию некоторой структуры значений (объектов). Последнее, пока отсутствует у Zigzag. Поэтому модель данных Sav Zigzag ближе к модели данных XML-СУБД, которая чаще называется просто, «иерархическая». Все значения (элементы) в этой модели иерархически произвольно связываются между собой и образуют дерево. Эту произвольность в XML-СУБД можно ограничить через DTD или XML-Schema. Поэтому типизация там присутствует. У Sav Zigzag для ограничения возможных значений используется скорее не типизация, а классификация. Мы можем просто заранее объявить класс перечислив множество его значений. Почти в соответствии с устаревшим определением типа в РМД. Например, класс «страна».
страна : [ Россия, США, …]
Возможные способы задания отношения для класса «страна» на языке Zigzag
{=страна: Ягугу} (материк: Европа);
страна: Ягугу (материк: Европа);
В первом случае отношение сформировано не будет, так как нет такой страны. Во втором случае отношение будет создано. При этом мы сможем посмотреть, что же такое Ягугу, связанное с материком Европа. Оказывается это страна
= *: Ягугу (материк: Европа)
13 дек 06, 13:25    [3529910]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
!
Думаю ответа мы не получим.


Видимо Вы правы
оппоненты открыто игнорируют неудобные вопросы
13 дек 06, 13:31    [3529974]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
Думаю ответа мы не получим.

Читать дискуссию надо внимательнее. Уже много раз было отвечено, PK есть часть идентифицируемого экземпляра а ссылка не есть часть. Как следствие различных ссылок у экземпляра может быть несколько и экземпляр не обязательно знает про их наличие. Полная аналогия с указателями(ссылками) в ООП. В СУБД реализуется это с помощью того же механизма индексов что и PK. Т.е. грубо эффективность можно считать равной в обоих случаях. А вот свойства с точки зрения пригладного програмиста разные.
13 дек 06, 13:57    [3530202]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)
Угумс, а теперь скажите, чем это будет отличаться от доступа по PK ???

Ничем, и это главное :)
13 дек 06, 14:09    [3530327]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
Александр Савинов
shuklin
... я сторонник принципа дополнительности Бора
который гласит, что ... (любобытно узнать)

В моей очень вольной интерпретации он гласит что допустимо одной сущности иметь взаимопротеворечивые свойства, поведение и т.п. Этот принцип был предложен Бором для описания свойства электрона как волны и как частицы. Он же корпускулярно-волновой дуализм используемый физиками.



Я пользуюсь принципом
"От общего к часному и от простого к сложному".
Этот принцип очень коррелирует с принципом Бора.
Но с вашей моделью никак.
13 дек 06, 14:12    [3530356]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
Хотелось бы увидеть такой же запрос в гипотетической нотации г-на Савинова. Чтобы тык-скыть заценить резкое уменьшение размера при как минимум сохранении той же понятности запроса.


Вот вам версия в SQL-подобном синтаксисе:
SELECT e.FIO, SUM( e.{Menu.dinnerid.emplID}.<count * dishid.cost> )
FROM Employee e 
WHERE COUNT( e.{Menu.dinnerid.emplID} ) > 100 
  AND dishdate > '01.02.2006' 
  AND name = 'Борщ' 

Ура!!! Я выиграл!! Моя версия короче!

А далее небольшой ликбез для ветеранов ревляционного движения.

В запросах важно понимать, что есть

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

Они могут находититься в разных таблицах. Так вот, подходы к организации запросов можно разделить соответственно на две группы:

1. сперва указывается что мы хотим получить, т.е. тип целевых записей, а потом уже как их ограничить. (пример, в SQL мы указываем сперва что надо вернуть, а потом уже как это ограничить)

2. сперва указываются исходные записи (ограничения), а потом они распространаются до целевых. (пример, мы указываем исходный объект, а далее с помощью имен полей проводим его до целевой таблицы)

В рельаной жизни оба подхода полезны или даже необходимы. Для легких запросов, когда ограничения просты, более удобен второй подход, например, точечная нотация (таких запросов большинство). Для тяжелых аналитических запросов, обычно многомерных, более удобен первый подход (их меньшинство). Так что никакой проблемы я здесь не вижу.

А проблема состоит в том, как поженить эти два подхода, чтобы они могли мирно сосуществовать. У меня решение есть и довольно естественное. А вот у Вас его нет. Так и что и говорить особо не о чем.
13 дек 06, 14:20    [3530434]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
shuklin
Читать дискуссию надо внимательнее. Уже много раз было отвечено, PK есть часть идентифицируемого экземпляра а ссылка не есть часть.


читать вопросы надо внимательнее

shuklin

Как следствие различных ссылок у экземпляра может быть несколько и экземпляр не обязательно знает про их наличие. Полная аналогия с указателями(ссылками) в ООП. В СУБД реализуется это с помощью того же механизма индексов что и PK. Т.е. грубо эффективность можно считать равной в обоих случаях. А вот свойства с точки зрения пригладного програмиста разные.


PK(UK)/FK

А логику/интерфейс в приложении можно нарисовать любую

хде научная новизна ???
13 дек 06, 14:21    [3530445]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Угумс, а теперь скажите, чем это будет отличаться от доступа по PK ???

Ничем, и это главное :)


Если нет никакой разницы (c) то об чем вообще вся эта дискуссия ???
13 дек 06, 14:23    [3530458]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
okdoky
Например, класс «страна».
страна : [ Россия, США, …]
Возможные способы задания отношения для класса «страна» на языке Zigzag
{=страна: Ягугу} (материк: Европа);
страна: Ягугу (материк: Европа);

А что такое отношение (в контексте Зигзага) и для чего оно нужно?
А класс и тип в Зигзаге это синонимы?
13 дек 06, 14:24    [3530477]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
я читаю внимательно.

Снасала вы пишете:
shuklin

С абстрактной точки зрения я уже надеюсь ответил. Просто существования экземпляра достаточно для того чтоб этот экземпляр был идентичен сам себе и неидентичен всему остальному.


потом:
shuklin
!
Думаю ответа мы не получим.

Читать дискуссию надо внимательнее. Уже много раз было отвечено, PK есть часть идентифицируемого экземпляра а ссылка не есть часть. Как следствие различных ссылок у экземпляра может быть несколько и экземпляр не обязательно знает про их наличие. Полная аналогия с указателями(ссылками) в ООП. В СУБД реализуется это с помощью того же механизма индексов что и PK. Т.е. грубо эффективность можно считать равной в обоих случаях. А вот свойства с точки зрения пригладного програмиста разные.



Пожалуйтста, расскажите еще раз, для тех кто в танке,
про алгоритм проверки идентичности и равенства?

Как там с закольцовкой ссылок, ась ?

Я Вас на этом уже ловил по ходу темы, вы съехали.
И опять вы начинаете тянуть старый баян.
13 дек 06, 14:31    [3530534]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

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

Пожалуйтста, расскажите еще раз, для тех кто в танке,
про алгоритм проверки идентичности и равенства?

Надоело. Те кто в танке идут читать документацию C# про отличие value type от reference type

А если в документации букофф много, то в школу, учиться читать.
13 дек 06, 14:39    [3530608]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
!

Пожалуйтста, расскажите еще раз, для тех кто в танке,
про алгоритм проверки идентичности и равенства?

Надоело. Те кто в танке идут читать документацию C# про отличие value type от reference type

А если в документации букофф много, то в школу, учиться читать.


слив защитан!!
13 дек 06, 14:43    [3530642]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
shuklin
А если в документации букофф много, то в школу, учиться читать.


слив защитан!!


С детскими капризами - в сад
13 дек 06, 14:48    [3530692]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов

Вот вам версия в SQL-подобном синтаксисе:
SELECT e.FIO, SUM( e.{Menu.dinnerid.emplID}.<count * dishid.cost> )
FROM Employee e 
WHERE COUNT( e.{Menu.dinnerid.emplID} ) > 100 
  AND dishdate > '01.02.2006' 
  AND name = 'Борщ' 
Ура!!! Я выиграл!! Моя версия короче!
Не хвались, идучи на рать, а хвались, идучи с…хм… рати.

Пока вы не дадите пояснения, говорить не о чем. Итак, для начала:

1. Что в предложении SELECT означают выражения count и dishid.cost? Для них нет никакого способа быть вычисленными из таблицы Employee — единственной таблицы в предложении FROM. То есть как построитель плана запроса догадается, из каких таблиц всей БД брать count и dishid.cost?

2. Тот же вопрос про поля dishdate и name в выражении WHERE. Откуда они должны быть взяты? И, соответственно, как в целом данный предикат из WHERE может быть вычислен для записей таблицы Employee?

3. Что означают угловые скобки?

4. Что означают фигурные скобки? И имя таблицы перед выражением в фигурных скобках?
13 дек 06, 15:02    [3530840]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
Вот вам версия в SQL-подобном синтаксисе:
SELECT e.FIO, SUM( e.{Menu.dinnerid.emplID}.<count * dishid.cost> )
FROM Employee e 
WHERE COUNT( e.{Menu.dinnerid.emplID} ) > 100 
  AND dishdate > '01.02.2006' 
  AND name = 'Борщ' 

Ура!!! Я выиграл!! Моя версия короче!
Но алфавит длинннее: {}, <>
13 дек 06, 15:10    [3530893]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
mir
Что в предложении SELECT означают выражения count и dishid.cost? Для них нет никакого способа быть вычисленными из таблицы


Я бы не стал так с плеча. :)

Скажите, Александр Савинов, а у Вас в "FROM Employee e" это самое Employee - это отоношение (как определяет РМД)?
13 дек 06, 15:28    [3531060]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить