Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
Мимопроходящий,

1. я не являюсь "личным папарацци Шуклина".

2. я не знаю, что такое "арсенал ПТ". (и, честно признаться, Ваш тон не вызывает у меня ни малешего желания узнать, что Вы хотели сказать!)

3. Мужик, если ты охотно бросаешся флеймить в "заезженной и надоевшей всем теме", то это - факт из твоей биографии.

4. И эта ... ты позволишь мне не отвечать в дальнейшем на твои бессодержательные наезды?
6 сен 05, 12:47    [1849805]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, Иван!
Ты пишешь:

Иван
ИF> 3. Мужик, если ты охотно бросаешся флеймить в "заезженной и надоевшей всем теме",
ИF> то это - факт из твоей биографии.
Дорогой Ваня, т/ф +7 (095) 3184083, гуляй лесом.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

6 сен 05, 12:49    [1849820]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
shuklin
Иван FXS
locky

> (ид_объекта, ид_атрибута, значение_атрибута)
Я тоже это понимаю так. Хотя не обязательно должна быть именно одна таблица.

- ага, можно завести таблиц по числу поддерживаемых типов ... красивое решение, правда?


В этом случае, вариант 3 из сабжевой статьи ИМХО предпочтительнее.

- а какие бывают ДРУГИЕ случаи? Когда в задаче все атрибуты объектов имеют один тип, что ли??
6 сен 05, 12:51    [1849839]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
Мимопроходящий
Дорогой Ваня, т/ф +7 (095) 3184083, гуляй лесом.


- ух-ты! Крута-а!! Куул хацкер?
6 сен 05, 13:00    [1849895]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

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

> (ид_объекта, ид_атрибута, значение_атрибута)
Я тоже это понимаю так. Хотя не обязательно должна быть именно одна таблица.

- ага, можно завести таблиц по числу поддерживаемых типов ... красивое решение, правда?


В этом случае, вариант 3 из сабжевой статьи ИМХО предпочтительнее.

- а какие бывают ДРУГИЕ случаи? Когда в задаче все атрибуты объектов имеют один тип, что ли??


Если я правильно понял, ты предложил для решения проблемы strong typed table использовать несколько различных таблиц по числу используемых типов атрибутов. Если так, то мне кажется идея из sharepoint более экономная.
Она предполагает заведение одной шаблонной таблицы с числом колонок достаточным для моделирования нескольких аттрибутов как одного так и разных типов. По одной колонке на предполагаемый аттрибут.

таблица выглядит like this:
create template (
ID int,
int01 int,
int02 int,
...
int99 int,
varchar01 varchar(100),
...
varchar99 varchar(100),
text01 text,
...
)

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

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

Все равно, как писали ранее, это решение проблемы а не ее отсутствие.
6 сен 05, 13:30    [1850128]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
Дмитрий, этот "вариант №3" я понял; он достаточно интересен, хотя очевидно не экономен (по ресурсам памяти/хранения).
_____________________

На самом деле, написано что-то уже слишком много ... хочется увидеть какое-то резюме, должен же быть достигнут какой-то конченсус!
_____________________

Мне кажется, основная (единственная?) "технологическая" претензия, которая может быть предъявлена РМД, - это то, что связывание (JOIN) начинает - по мере роста таблиц - требовать непомерно много ресурсов.

Ты, якобы, имеешь какое-то решение этой проблемы, но я - честно! - пока его не понял.

Более того, мне кажется, что РАДИКАЛЬНОЕ решение этой проблемы ПРИНЦИПИАЛЬНо невозможно: в конце-концов данные (и на диске, и в памяти) хранятся как бы в ЛИНЕЙНОЙ форме (т.е. - бит за битом), а значит, - чтобы архивировать информацию о сложно-структурированной реальности, - мы неизбежно должны сохранять информацию о СТРУКТУРЕ в виде АДРЕСОВ-ССЫЛОК. А при восстановлении структуры - разыскивать ее "части" по их адресам.

А это и есть - так или иначе - тот самый JOIN!
6 сен 05, 13:59    [1850366]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Иван FXS
Мне кажется, основная (единственная?) "технологическая" претензия, которая может быть предъявлена РМД, - это то, что связывание (JOIN) начинает - по мере роста таблиц - требовать непомерно много ресурсов.


Можно получить какие-либо обоснования по этому тезису ?
6 сен 05, 14:18    [1850498]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
ээээ ... обоснование, что это - проблема? Или что "основная (единственная?)"?

Вам приходится работать с таблицами, содержащими миллионы записей? Комфортно ли их связывать, даже если только две? А если три??
6 сен 05, 14:39    [1850642]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Приходилось
6 сен 05, 14:42    [1850653]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Чудес не бывает. Имеется несколько механизмов выполнения Join для различных случаев жизни. Сомневаюсь, что Мозк предложит в этом отношении что-то принципиально новое.
6 сен 05, 14:43    [1850663]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
Нутак, и я, вроде, то же самое пытался сказать: что "чудес не бывает"!
6 сен 05, 14:46    [1850682]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
дураг с инецеативой
Guest
Иван FXS

Мне кажется, основная (единственная?) "технологическая" претензия, которая может быть предъявлена РМД, - это то, что связывание (JOIN) начинает - по мере роста таблиц - требовать непомерно много ресурсов.

Не в РМД, а в SQL СУБД. Но возможно, что решение
уже есть
6 сен 05, 14:52    [1850740]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
serg99
Member

Откуда:
Сообщений: 422
Иван FXS
mir
Как кандидат наук кандидату наук настоятельно советую переключиться со звонких статей к фундаментальному самообразованию в области систем баз данных.

- mir, если за тем, что обсуждает Дмитрий Шуклин нет совсем никакого содержания, то почему эти ветки вызывают такой большой интерес - именно здесь, на ПРОФЕССИОНАЛЬНОМ форуме?

А если содержание есть, если некая "проблема схвачена", тоне могли бы Вы (как кандидат наук) попробовать ее сформулировать? Без - абсолютно излишнего - пафоса!

Я думаю проблема видна на примере скажем стандарта SQL-2003. Какой то авиаконструктор сказал, что летают только красивые самолеты. Мне кажется что SQL становится все менее красивым. Конечно начавшись как "простой запросный язык легкий для освоения непрофессионалом" он живет своей жизнью (как например тот же Бейсик). Однако стандарт на язык объемом под 1500 страниц - это уже черезчур. Конечно нельзя ставить знак равенства между РМД и SQL, тем не менее превращение SQL в "монстра" может свидетельствовать о некоторой неадекватности SQL (и РМД на которую он опирается) при решении ряда практических задач.
6 сен 05, 14:57    [1850789]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Иван FXS
Мне кажется, основная (единственная?) "технологическая" претензия, которая может быть предъявлена РМД, - это то, что связывание (JOIN) начинает - по мере роста таблиц - требовать непомерно много ресурсов.
Давайте не путать подобно г. Шуклину понятия. РМД -- это модель данных, это строго логическая концепция. Она не налагает никаких ограничений на внутренние механизмы реализации. Модели данных не могут быть предъявлены "технологические" претензии. Любой разработчик РСУБД имеет право и обязан делать все, что угодно для повышения производительности обработки данных. Поэтому вопросы производительности могут рассматриваться только применительно к конкретным СУБД, т.е. применительно к конкретным реализациям.
6 сен 05, 14:59    [1850804]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
Да вроде, друг с инецеативой, именно в Реляционной Модели:
если мы в одной табличке храним описания кабинетов, включая уникальный ключ [id_Кабинет], а в другой - описание служащих, включая поле [id_Кабинет], указывающее в каком кабинете данный служащий сидит,
- то это УЖЕ sql, или еще пока только РМД?
6 сен 05, 15:01    [1850818]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
Не согласен, mir!

Когда мы РАЗЪЕДИНЯЛИ (кабинеты - в одну таблицу, служащих - в другую) тогда мы и СОЗДАЛИ себе (будущую) проблему связывания!

А могли бы ведь и не разъединять (например, отказавшись от удобства иметь по одной записи на каждую "строчку" справочника!). Вели бы ОДНУ сплошную таблицу "фактов" (как на листе Excel) - не было бы никакой "проблемы связывания" ... Были бы, правда, другие!
6 сен 05, 15:08    [1850869]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ладно, сподвигли на лирическое отступление.

Сейчас воюем с биллинговой системой одной известной компании. Так они там сделали объект баланс. Просто так, без затей. В одной строке хранят в CSV баланс, код валюты, пороги отключения, много чего еще. Из этого + .Net трехзвенка вытекают такие проблемы с производительностью, что ChangeBalance выполняется чуть меньше секунды, это при том что в секунду таких операций планировалось 1000.

Конец отсутпления

Да, мы можем хранить объект целиком. Но что мы будем делать, когда нам понадобится дставление объектов в ДРУГОМ разрезе ???
6 сен 05, 15:15    [1850922]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
Так может нужно искать компромисы? И делать более ГИБКИЕ модели данных, чем РМД, которая является через чур жесткой?

Может быть об этом Shuklin и пытается говорить?
6 сен 05, 15:21    [1850965]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
ggv
Member

Откуда:
Сообщений: 1810
нифига!
Ни о каких компромисах он не пытается говрить!
Перечитайте статью .
6 сен 05, 15:24    [1850986]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Иван FXS wrote:
> locky
>
> > (ид_объекта, ид_атрибута, значение_атрибута)
> Я тоже это понимаю так. Хотя не обязательно должна быть именно одна
> таблица.
>
>
> - ага, можно завести таблиц по числу поддерживаемых типов ... красивое
> решение, правда?
Красиво, но непродуктивно, с точки зрения производительнотси

>
> locky
> Если не сложно, поясните, с какими сложностями Вы сталкивались (или
> какие можете себе представить).
>
>
> - придется запихивать ВСЕ значения в поле с НАИБОЛЕЕ СЛАБЫМ форматом и
> от "низкоуровневых" механизмов обеспечения типизации перейти к
> высокоуровневым.
> Ха-ха, всего-то - как говорится...
это как? Вы предлагаете запихивать int в varchar? Я правильно Вас понял?


--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

6 сен 05, 15:24    [1850987]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
дураг с инецеативой
Guest
согласен с mir.

Иван FXS
Да вроде, друг с инецеативой, именно в Реляционной Модели:
если мы в одной табличке храним описания кабинетов, включая уникальный ключ [id_Кабинет], а в другой - описание служащих, включая поле [id_Кабинет], указывающее в каком кабинете данный служащий сидит,
- то это УЖЕ sql, или еще пока только РМД?

Это именно SQL, т.к. фразы "в табличке храним", "поле" - есть описание реализации.

В РМ только описываются отношения
Кабинет ([id_Кабинет], [описание]),
Служащий([id_Служащий], [id_Кабинет], [описание])
и ограничения :
a) ∀ k ∈ Кабинет card{r ∈ Кабинет | r[id_Кабинет] = k[id_Кабинет]} = 1
b) ∀ a ∈ Служащий ∃1 k ∈ Кабинет : a[id_Кабинет] = k[id_Кабинет]
6 сен 05, 15:26    [1850994]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
Возможно я совсем отстал от жизни, но я продолжаю настаивать, что:
"таблички", то есть - хранение данных в виде неупорядоченных набов записей, каждая из которых (в пределах отного набора = таблички) имеет одну и ту же структуру полей
- тут никаким SQL пока даже и не пахнет.

SQL - это способ описания (задания) ОПЕРАЦИЙ которые можно (нужно) произвести над данными "табличек" ...
Но сами по себе таблички, как способ хранения (организации) данных:
1. вполне могут знай себе существовать без всяких там "операций"
2. могут обрабатываться вообще без SQL! С слышили, наверное, такие слова: DAO, OpenRecordset, MoveFirst, MoveNext, Search, Edit, Update!? Или это, скажете, SQL??
6 сен 05, 15:43    [1851093]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, Иван!
Ты пишешь:

Иван
ИF> 1. вполне могут знай себе существовать без всяких там "операций"
ИF> 2. могут обрабатываться вообще без SQL!
ИF> С слышили, наверное, такие слова: DAO, OpenRecordset, MoveFirst, MoveNext, Search,
ИF> Edit, Update!? Или это, скажете, SQL??
Вань, ты не смеши народ больше.
Ту люди с базами таки работают.

Как можно, не имея даже базовых знаний,
пытаться что-то критиковать?..

Ужос, нах. (С)

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

6 сен 05, 15:49    [1851131]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Догоняющий жизнь...
Guest
SQL - это способ описания (задания) ОПЕРАЦИЙ
Тюююю....! А как же DDL? А куда же делся Креате тэйбл?

слышили, наверное, такие слова.....? Или это, скажете, SQL??
А что - это РМД?
6 сен 05, 15:50    [1851141]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2370
locky
это как? Вы предлагаете запихивать int в varchar? Я правильно Вас понял?

- я предлагаю? Или Вы предлагаете?

А "запихивать", боюсь, придется все в MEMO, если среди атрибутов
(коих - всех! - значения мы с Вами решили хранить в единой таблице [ид_объекта, ид_атрибута, значение_атрибута])
- найдется хоть один, который (по бизнес логике) требует поля MEMO.
6 сен 05, 15:51    [1851146]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить