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

Откуда: Северная Калифорния
Сообщений: 686
Александр Зуев

Нет, мы не можем сменить систему индексации/поиска данных, но есть надежда что ребята из ФМИ, прежде чем декларировать возможность ФМ шарить 8-террабайтную базу между одновременно работающими 250 пользователями, заложили в него некие механизмы. Какие именно - неизвестно.


Фишка в том, что универсальных механизмов хранения данных не существует. Одни механизмы хорошо заточены под одну задачу, и плохо - под другую. То как мы будем хранить данные зависит от того как мы будем их использовать. Например если мы будем выбирать данные по условию "А =..." то нам может лучше подойти хэш-таблица, а если по условию "... <= А <= ..." то скорее всего лучше подойдет сбалансированное дерево. А еще может куча подойти, в зависимости от того что и как мы читаем и пишем. "Магических" универсальных структур данных не бывает. И ребята из ФМ их скорее всего не придумали, как не придумали их Дональд Кнут, Джеффри Ульман, и коллективы разработчиков в Оракле, DB2 итд. "Магической серебрянной пули" не бывает.

Насчет "согласованного чтения" вынужден вас расстроить. ФМ его не поддерживает, а поддерживает простенькую блокировку. Допустим в таблице 5 записей. Я начал читать с первой записи (типа решил среднее посчитать или бэкап сделать), вы в это время заблокировали 4ю. Я дошел до 4й записи и жду пока вы ее отпустите. Вы "прибили" ее неким эквивалентом commit, отпуская ее и я прочитал НОВОЕ значение записи. То есть не то что было на момент когда я начал читать, а то которое "материализовалось" уже после. А теперь открываем любой учебник по СУБД и смотрим какие аномалии бывают при уровне изоляции транзакций read commited. Вот и все.
15 сен 04, 00:03    [959701]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
если мы будем выбирать данные по условию "А =..." то нам может лучше подойти хэш-таблица, а если по условию "... <= А <= ..." то скорее всего лучше подойдет сбалансированное дерево. А еще может куча подойти, в зависимости от того что и как мы читаем и пишем.

Ваши рассуждения натолкнули меня на мысль. Структура файла ФМ очень сложна. Новые записи пожирают дисковое пространство со страшной силой. Что если они реализовали три типа индексации, и используют тот-или иной индекс в зависимости от ситуации?

Или другой вариант, основной инструмент структурирования БД ФМ - реляционные связи. В момент описания новой реляционной связи ФМ автоматически включает индексацию релируемого поля. Сама реляция описывает условие выборки. Что если в момент описания реляционной связи ФМ строит оптимальный для данного условия выборки индекс?

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



Насчет "согласованного чтения" вынужден вас расстроить. ФМ его не поддерживает, а поддерживает простенькую блокировку.

Так ведь я же и объяснял как в ФМ6 с помощью одновременной блокировки нескольких записей обеспечить "согласованное чтение" - две записи блокируются, а затем комитятся одновременно. Такой подход гарантирует что изменения обоих записей будут записаны в файл после завершения операции чтения.



Я дошел до 4й записи и жду пока вы ее отпустите.

Нет, блокировка записи в ФМ не запрещает чтение. Дойдя до 4-й записи Вы продолжите чтение исходных (не измененных) данных.


Вы "прибили" ее неким эквивалентом commit, отпуская ее и я прочитал НОВОЕ значение записи.

А почему, собственно, ФМ должен работать так, как Вы описываете? Ведь это явно нарушает согласованность. Я понимаю если бы речь шла о чистом ФС, в котором операции чтения/записи выполняет каждый клиент по отдельности. Но в ФМ все эти операции выполняет сервер. Если сервер получил от одного клиента запрос на чтение некоторого диапазона записей, а позже, когда он ещё не закончил чтение, он получает от друго клиента запрос на изменение одной из записей из этого диапазона. Зачем же он станет выполнять запрос на изменение? Он ведь в состоянии понять что это изменение приведет к нарушению согласованности, ведь команда на изменение поступила после начала чтения, что же ему помешает закончить чтение а потом внести изменения?
15 сен 04, 00:46    [959719]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Кстати, господа оппоненты, вы зря напрягаетесь на терабайты. В ФМ теперь простое поле может содержать до 2 ГБ текста, а поле типа Container, в которое можно было засунуть картинку, мувик или саундтрэк, теперь может содержать и 2 ГБ файл любого типа. Так что, при нынешних способностях Фотошопа, забить дисковый массив большого труда не составит - всего-то несколько тысяч записей.
15 сен 04, 07:48    [959811]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
АЗ
Кстати, господа оппоненты, вы зря напрягаетесь ...
Уже, по-моему, никто не напрягается.
Все оставили вас в покое. Т.к. судя по всему это действительно не лечится :((

Единственно бывает интересно почитать посты Злого.
Успехов.
15 сен 04, 10:33    [960230]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Александр Зуев

1)
Так ведь я же и объяснял как в ФМ6 с помощью одновременной блокировки нескольких записей обеспечить "согласованное чтение" - две записи блокируются, а затем комитятся одновременно. Такой подход гарантирует что изменения обоих записей будут записаны в файл после завершения операции чтения.

...
2)
Я дошел до 4й записи и жду пока вы ее отпустите.

Нет, блокировка записи в ФМ не запрещает чтение. Дойдя до 4-й записи Вы продолжите чтение исходных (не измененных) данных.


Ваши утверждения идущие друг за другом противоречат друг другу. Чтобы такой подход гарантировал "что изменения обоих записей будут записаны в файл после завершения операции чтения",чтение должно блокироваться записью. Для обеспечения целостности в "блокирующей" модели блокировка должна запрещать чтение, иначе никакой согласованности не будет.
Почитайте всё таки книжки про "concurency control" , это не "учебники ассемблера" для разработчиков на паскале, это учебники по "основам программирования" для этих самых разработчиков, которые несут вечные ценности. Можно конечно читать рукодство по turbo Pascal xxxxx, но значительно полезней почитать Кнута.


Александр Зуев
Если сервер получил от одного клиента запрос на чтение некоторого диапазона записей, а позже, когда он ещё не закончил чтение, он получает от друго клиента запрос на изменение одной из записей из этого диапазона. Зачем же он станет выполнять запрос на изменение? Он ведь в состоянии понять что это изменение приведет к нарушению согласованности, ведь команда на изменение поступила после начала чтения, что же ему помешает закончить чтение а потом внести изменения?

Каким образом Вы предлагаете осуществить это "знание"? Допустим запрос на чтение выполняет сканирование по диапазону дат, запрос на изменение изменяет записи по конкретным идентификаторам, каким образом сервер должен опредилить, что эти идентификаторы попадают в тот диапазон дат?
Хранить идентификаторы всех прочитанных записей ( например парочки миллионов), а потом их удалять?
Нет, конечно если выстроить ВСЕ задания в последовательную очередь, то всё конечно само собой сериализуется, но вот только паралельность и масштабируемость исчезнет.

Александр Зуев
Ваши рассуждения натолкнули меня на мысль. Структура файла ФМ очень сложна. Новые записи пожирают дисковое пространство со страшной силой. Что если они реализовали три типа индексации, и используют тот-или иной индекс в зависимости от ситуации?

Или другой вариант, основной инструмент структурирования БД ФМ - реляционные связи. В момент описания новой реляционной связи ФМ автоматически включает индексацию релируемого поля. Сама реляция описывает условие выборки. Что если в момент описания реляционной связи ФМ строит оптимальный для данного условия выборки индекс?

Если бы всё было так, то Вы бы имели совершенно ужасную систему, выполняющую кучу лишних действий по поддержанию ненужных структур и умирающую при внесении изменений в данные.
Что бы "в момент описания реляционной связи" строить "оптимальный для данного условия выборки индекс" надо иметь статистику по количеству и распределению данных в связываемых таблицах, Вы её указываете или может всегда сначала заполняете таблицы данными в соответствующем колличестве?
15 сен 04, 10:49    [960312]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Я и ёжик
Ваши утверждения идущие друг за другом противоречат друг другу. Чтобы такой подход гарантировал "что изменения обоих записей будут записаны в файл после завершения операции чтения",чтение должно блокироваться записью.

Нет, если чтение заблокировать на середине, то выполнится запись, а потом разблокируется и продолжится чтение, что может привести к нарушению целостности. Я имел ввиду как раз наоборот - запись блокируется до завершения операции чтения, если чтение было начато раньше. Тогда будут прочитаны исходные (не измененные) данные, и целостность будет сохранена. Вы же сами выше писали что "если выстроить ВСЕ задания в последовательную очередь, то всё конечно само собой сериализуется".



Каким образом Вы предлагаете осуществить это "знание"? Допустим запрос на чтение выполняет сканирование по диапазону дат, запрос на изменение изменяет записи по конкретным идентификаторам, каким образом сервер должен опредилить, что эти идентификаторы попадают в тот диапазон дат?


В ФМ6 - это можно сделать довольно просто. Там, как я писал ранее, все расчеты выполняет клиент. При первом обращении по реляции весь индекс релируемого поля передается клиенту. Клиент локально строит некую выборку идентификаторов записей отвечающих нужному диапазону дат, и тут происходит одно из двух:

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

2. Если речь идет о расчете суммы, то клиент вынужден передать серверу всю выборку идентификаторов сразу, чтобы сразу получить все данные по суммируемому полю и, собственно, просуммировать их.

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

В ФМ7 - сложнее. Там операцию суммирования выполняет сервер. Я могу конечно пофантазировать как ФМ7 обеспечивает целостность, но боюсь показаться смешным - с чистым КС я пока слабо знаком.



Если бы всё было так, то Вы бы имели совершенно ужасную систему, выполняющую кучу лишних действий по поддержанию ненужных структур и умирающую при внесении изменений в данные.
Что бы "в момент описания реляционной связи" строить "оптимальный для данного условия выборки индекс" надо иметь статистику по количеству и распределению данных в связываемых таблицах

Насчет построения оптимального индекса в момент описания реляционной связи пожалуй Вы правы. Я позже подумал что вообще-то на одно и тоже релируемое поле может быть две и более полностью противоположные связи да и поиск в ФМ свободный. В общем, неудачная идея.

А вот насчет одновременного ведения нескольких типов индексов - не удивлюсь если выяснится что ФМ так и делает. Вспомните пример с КЛАДР, который я приводил на четвертой странице. Там в таблице всего 15 хранимых полей, только 5 из них индексированные, и толко в двух из индексированных полей данные присутствуют по всей таблице (пустые поля в ФМ не занимают место). В тестовом файле было 740 тыс. записей, а занял он 760 мег. То есть на запись приходилось по килобайту. Многовато для 15-и полупустых полей.
15 сен 04, 12:42    [960829]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
а откуда 15 полей? давайте сверим таблицы. У меня вот такая основная таблица:
CREATE TABLE addres (
	id int IDENTITY (100000, 1) NOT NULL , -- ключ *
	parent int NULL ,  -- *
	id_name int NOT NULL , -- код названия *
	level int NOT NULL ,  -- уровень элемента(регион, город и т.д.)
	id_abbr int NOT NULL ,  -- код аббревиатуры(пос, ул, пр-кт и т.д.)
	code varchar (20) NOT NULL , -- номер в справочнике 
	idx varchar (6) NULL , -- почтовый индекс
	gni char (4) NULL ,  -- код НИ
	crdate datetime DEFAULT (getdate()), -- дата создания/последнего редактирования записи
	manual tinyint  DEFAULT (0),  -- флаг было ли оно изменено автоматически или ручками
	chng_id int NULL , -- некий номер для синхронизации 
)
Ну и еще есть 5 таблиц, но там не больше 5 полей в каждой. Индексировано только 3 поля(отметил звёздочками)
15 сен 04, 13:09    [961020]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
SergSuper
а откуда 15 полей?

У меня в одну таблицу слиты все 5 таблиц КЛАДР (дома, улицы, сокращения...) Данные располагаются каскадом. В ФМ так можно, поскольку пустые поля не занимают место.

SergSuper
давайте сверим таблицы

Ну давайте...

NAME Text Indexed 
SOCR Text  
CODE Text  
INDEX Text  
GNINMB Text  
UNO Text  
OCATD Text  
STATUS Text  
KORP Text  
SCNAME Text Indexed 
SOCRNAME Text  
KOD_T_ST Text  
LEVEL Number Indexed 

COMMONOne Calculation (Number)Indexed = 1 

KladrKeyFilterCalc Calculation (Text) Indexed = Substitute(Substitute(Substitute(Substitute(Substitute(

CODE & 
"¶c" & 
"¶c n1" & 
"¶c n2" & 
"¶c n3" & 
"¶c s" & 
"¶c s n1" & 
"¶c s n2" & 
"¶c s n3",

"c", Case(

(Length(CODE) = 11 or Length(CODE) = 13) and TextToNum(Middle(CODE, 12, 2)) = 0, 

Case(
TextToNum(Middle(CODE, 3, 9)) = 0, "0", 
TextToNum(Middle(CODE, 6, 6)) = 0, Left(CODE, 2), 
TextToNum(Middle(CODE, 9, 3)) = 0, Left(CODE, 5), 
Left(CODE, 8)), 

Length(CODE) = 17 and TextToNum(Middle(CODE, 16, 2)) = 0, Left(CODE, 11), 

Length(CODE) = 19, Left(CODE, 15), 

"X")), 

"s", SOCR), 
"n1", Left(NAME, 1)), 
"n2", Left(NAME, 2)), 
"n3", Left(NAME, 3))

Последнее поле (KladrKeyFilterCalc) вероятно самое большое. В нем расчитывается и хранится реляционный ключ, по которому работают все выборки:

01003000020000700
01003000020
01003000020 С
01003000020 Со
01003000020 Сов
01003000020 ул
01003000020 ул С
01003000020 ул Со
01003000020 ул Сов

Поле COMMONOne - так, служебное.
15 сен 04, 13:35    [961195]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Александр Зуев

Нет, если чтение заблокировать на середине, то выполнится запись, а потом разблокируется и продолжится чтение, что может привести к нарушению целостности. Я имел ввиду как раз наоборот - запись блокируется до завершения операции чтения, если чтение было начато раньше. Тогда будут прочитаны исходные (не измененные) данные, и целостность будет сохранена.
О, наконец то кое-что начало пробиваться, да запись ТАКЖЕ должна блокироваться чтением ( при использовании чисто "блокировочного" механизма управления паралельными заданимми) как и чтение записью.
Александр Зуев

Вы же сами выше писали что "если выстроить ВСЕ задания в последовательную очередь, то всё конечно само собой сериализуется".
Да, это действительно так серия целостных транзакций выполненых последовательно пререводит БД из одного целостного состояния в другое. Но такой метод означает полный отказ от паралельности и соответственно низкую масштабируемость.

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

Упссс... как же это он увидит, если Вы чуть выше писали "запись блокируется до завершения операции чтения", неувязочка, не блокируется получается ничего. Я конечно понимаю что "пофиг нам выша неувязочка" ;).


Александр Зуев

В ФМ6 - это можно сделать довольно просто.
...

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

А важно вот что. Вы предлагаете серверу держать ( ну или передавать ему с клиента) некоторый список идентификаторов строк с указанием операции которая соответствует операции выполняемой со строкой ( ну допусим, S (Share) для чтения и X ( eXclusive) для записи). И при выполнении некой операции проверять в этом списке начличие идентификатора требуемой строки и в зависимости от результата выполнять операцию или нет.
Знаете как называется такой список и его элементы? Точно, таблица блокировок и блокировки уровня строки. Вот мы и изобрели велосипед!

А чтобы механизм обеспечения целостности работал, как мы выяснили запись должна блокировать чтение и наоборот, чего в ФМ мы, по Вашим словам("блокировка записи в ФМ не запрещает чтение","буквально увидит как изменится значение в поле измененном другим клиентом "), не наблюдаем ( ну еще должен соблюдаться протокол блокирования, называемый в народе "2 phase locking" но об этом наверное лучше пока не будем).


Александр Зуев
В ФМ7 - сложнее. Там операцию суммирования выполняет сервер. Я могу конечно пофантазировать как ФМ7 обеспечивает целостность, но боюсь показаться смешным - с чистым КС я пока слабо знаком.

Не надо фантазировать, нет специальных механизмов обеспечения целостности ( то бишь управления паралельными заданиями) для КС или ФС, они однотипны ( просто в ФС тяжелее реализуются ).

Александр Зуев

А вот насчет одновременного ведения нескольких типов индексов - не удивлюсь если выяснится что ФМ так и делает.

Тогда никому больше об этом не рассказывайте, особенно клиентам, они знаете ли не любят когда их ресурсы расходуют впустую...
15 сен 04, 14:26    [961569]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Я и ёжик
как же это он увидит, если Вы чуть выше писали "запись блокируется до завершения операции чтения"

Если пользователь видит запись, значит операция чтения уже закончилась, иначе что же он видит как не результат удачно завершившейся операции чтения?! Следовательно теперь может выполнится операция записи. И как только она выполнится, для всех клиентов имеющих удовольствие лицезреть в текущий момент измененную запись будет вызвана повторная операция чтения этой записи. Тогда они и увидят изменения.



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

Не стесняйтесь!

При поиске по не индексированному полю в ФМ6 клиенту передается весь контент поля и, как и в случае с индексированным полем, идентификаторы всех записей.



Знаете как называется такой список и его элементы? Точно, таблица блокировок и блокировки уровня строки. Вот мы и изобрели велосипед!

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

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

Судя по моим ощущениям, в ФМ используется полностью автоматическая изоляция транзакций - со всеми вытекающими.




А чтобы механизм обеспечения целостности работал, как мы выяснили запись должна блокировать чтение и наоборот

Нет, мы выяснили что только "наоборот" - чтение блокирует запись. Так же мы выяснили что запись блокирует запись. А вот что запись блокирует чтение, в том смысле что заблокированную для записи запись нельзя читать пока её не разблокируют мы не выяснили. В ФМ она читается запросто - естественно её исходное значение (до изменения).



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

Что Вы людей пугаете?! Это ведь всего навсего мои предположения. Работает достаточно быстро и устойчиво, а как - секрет фирмы.
15 сен 04, 16:44    [962333]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Александр Зуев

А чтобы механизм обеспечения целостности работал, как мы выяснили запись должна блокировать чтение и наоборот

Нет, мы выяснили что только "наоборот" - чтение блокирует запись. Так же мы выяснили что запись блокирует запись. А вот что запись блокирует чтение, в том смысле что заблокированную для записи запись нельзя читать пока её не разблокируют мы не выяснили. В ФМ она читается запросто - естественно её исходное значение (до изменения).

Это Вы не выяснили, чтобы выяснить обратитесь к соответствующей литературе, например Concurrency Control & Recovery in Database Systems, By Ph. Bernstein .
Ну или учебник "по ассемблеру" от Гарсии-Малины с компанией или от какой другой компании.
Можете еще подумать над нашим любимым примером с длительной читающей транзакцией при след последовательности действий:
1) Читающая транзакция начинается, начинает читать записи, до записей x и y ещё не добралась.
2) Изменяющая транзакция блокирует записи х и y.
3) Изменяющая транзакция изменяет записи x и y, но еще не фиксирует их
(не выходит из записи, если я правильно запомнил вашу терминологию).
4) Читающая транзакция добралась до записи x, и считала её значение ( пока еще старое) несмотря на то что запись x заблокирована по записи. И кстати говоря, умудрилось на эту же запись наложить блокировку чтения ("чтение блокирует запись" (с) АЗ, дабы другие транз.... простите операции не смогли её изменить).
5) Изменяющая транзакция "выходит из записи", т.е фиксируется.
Значения в x и y изменены.
6) Читающая транзакция успешно доберается до Y и считавает уже новое значение...

Александр Зуев

В ФМ она читается запросто - естественно её исходное значение (до изменения).

Т.е ФМ не обеспечивает "автоматической" изоляции ("В ФМ она читается запросто "), "ощущения на 12 странице" Вас обманули. На самом деле для "автоматической" изоляции даже не достаточно блокировки чтения записью, записи чтением и записи записью, надо ещё предикаты блокировать...
Ну и снова Concurrency Control & Recovery in Database Systems, By Ph. Bernstein .
15 сен 04, 17:25    [962509]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Я и ёжик
1) Читающая транзакция начинается, начинает читать записи, до записей x и y ещё не добралась.
2) Изменяющая транзакция блокирует записи х и y.
3) Изменяющая транзакция изменяет записи x и y, но еще не фиксирует их
(не выходит из записи, если я правильно запомнил вашу терминологию).
4) Читающая транзакция добралась до записи x, и считала её значение ( пока еще старое) несмотря на то что запись x заблокирована по записи. И кстати говоря, умудрилось на эту же запись наложить блокировку чтения ("чтение блокирует запись" (с) АЗ, дабы другие транз.... простите операции не смогли её изменить).
5) Изменяющая транзакция "выходит из записи", т.е фиксируется.
Значения в x и y изменены.
6) Читающая транзакция успешно доберается до Y и считавает уже новое значение...

1) Читающая транзакция начинается, начинает читать записи, до записей x и y ещё не добралась
2) Изменяющая транзакция блокирует записи х и y - блокирует на запись, не на чтение!
3) Изменяющая транзакция изменяет записи x и y, но еще не фиксирует их
4) Читающая транзакция добралась до записи x, и считала её значение ( пока еще старое)
5) Изменяющая транзакция "выходит из записи", т.е ПЫТАЕТСЯ фиксироваться

Здесь данные зависают в буфере, поскольку имеет место попытка записи в диапазон читающей транзакции, что может вызвать нарушение целостности

6) Читающая транзакция успешно доберается до Y и считавает СТАРОЕ значение

7) Читающая транзакция успешно завершается, данные изменяющей транзакции из буфера пишутся в файл.
15 сен 04, 17:54    [962610]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Я и ёжик
надо ещё предикаты блокировать...[/url].

По приведенной ссылке можно найти как именно реализуется блокировка по предикату? Нет ли еще каких ссылок, чтобы узнать об этом подробнее?
15 сен 04, 18:25    [962725]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
ну я
Я и ёжик
надо ещё предикаты блокировать...[/url].

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

Глава 3.7 The Phantom Problem стр. 64 и в частности подпункт Index Locking стр. 67.

В двух словах имеется ввиду блокировка диапазона ключей (Key Range Lock)
индекса или если нет подходящего индекса то всего объекта ( для РСУБД это будет таблица).

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

Вот здесь ("Критика уровней изолированности в стандарте ANSI SQL" Х. Беренсон, Ф. Бернштейн, Д. Грэй, Д. Мелтон, Э. О'Нил, П. О'Нил) тоже должно быть при обсуждении уровня Serializable, проверить опять же немогу, но на сколько помню лучше смотреть оригинальную статью, в переводе вроде были ошибки, в частности в таблицах описывающих соответствующие уровни изоляции.
16 сен 04, 11:46    [963975]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Я и ёжик

В двух словах имеется ввиду блокировка диапазона ключей (Key Range Lock)
индекса или если нет подходящего индекса то всего объекта ( для РСУБД это будет таблица).

Примерно так и думал :-(.
Либо получение по условию по индексам списка попавших под условие записей и блокирование их списком, либо плюнуть на все и эскалировать блокировку до всей таблицы. Эх, а так хотелось чего-то свеженького, скажем такое устройство системы синхронизации, чтобы оно могло выполнять синхронизацию предикативно. Не в Ваш огород камень, просто мысли вслух.
16 сен 04, 14:28    [964884]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
ну я
Примерно так и думал :-(.
Либо получение по условию по индексам списка попавших под условие записей и блокирование их списком, либо плюнуть на все и эскалировать блокировку до всей таблицы.

Не совсем, имеется ввиду именно блокирование некой входной точки (entry) индекса, а не получение списка записей и блокирование их списком ( последнее как раз не поможет при добовлении новой записи попадающей в список).
Есть еще вариант, который напрямую называется "блокировкой предикатов",
т.е. в таблицу блокировок заносится сам по себе предикат. Два предиката считаются конфликтующими если есть элементы данных удоволетворяющие обоим предикатам. Но, это считается дорогим и труднореализуемым способом, а поэтому широко не используется.
16 сен 04, 15:09    [965105]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Я и ёжик

Не совсем, имеется ввиду именно блокирование некой входной точки (entry) индекса, а не получение списка записей и блокирование их списком ( последнее как раз не поможет при добовлении новой записи попадающей в список).

Вот это уже мне понравилось, спасибо. Хочу такую штуку к cache примерить. Но, похоже, в языке таких средств нет, а вот внешним плагинчиком - вполне может быть.
16 сен 04, 15:33    [965248]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Еще подумалось - но тогда такой индекс должен быть небалансированным? По крайней мере на время таких блокировок.
16 сен 04, 15:35    [965254]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
ну я
Еще подумалось - но тогда такой индекс должен быть небалансированным? По крайней мере на время таких блокировок.

Речь как я понимаю о индексах на основе B-деревьев.
Нет, я думаю просто операции которые вызывают необходимость автобаллансировки будут ждать снятия блокировок, ну или получат отлуп не дождавшись.
Вообще блокировка на древесных структурах ( Tree locking) это отдельная песня и специальные протоколы, в том числе и для B-tree ( для которых свои особенности), честно говоря я глубоко в это не вникал :(. У того же Бернштайна по этому поводу есть подглава 3.13.
Но поскольку это всё таки учебник, то возможно там многое упрощено и опущено и для реальной реализации Вам придется поискать более глубокие источники или что то досочинить.
16 сен 04, 16:21    [965509]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
Кстати, друзья мои, вчера я попал еще на одну фирму, где закуплена за большие деньги 1С, и не используется - вот Вам еще один пример использования SQL на предприятиях небольшого ранга.
17 сен 04, 11:37    [967688]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
а 1С то здесь при чем???
17 сен 04, 12:13    [967895]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
Внимательно почитайте что было написано в начале. Незачем использовать SQL на предприятиях среднего и малого бизнеса. 1С базируется на SQL.
На таких предприятиях ФМ самая подходящая среда для работы.
17 сен 04, 16:25    [969249]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Внимательно почитайте что было написано в начале

ты не мудри, ты пальцем покажи
а то в 17 страницах тяжеловато ориентироваться

Незачем использовать SQL на предприятиях среднего и малого бизнеса.

LOL

1С базируется на SQL

уже даже не LOL
1C на бреде Нуралиева базируется
Поэтому на предприятиях малого и среднего бизнеса не стоит использовать бред Нуралиева.
17 сен 04, 16:42    [969349]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
По поводу SQL, бред несете, господа. Во-первых SQL - всего лишь язык, позволяющий писать запросы не применяя циклы. Существуют библиотеки позволяющие гонять SQL-запросы против столь любимых вами файлов. Грубо говоря парсер SQL и примитивный транслятор этих запросов в операции read/write файловой системы. Чем отличается такая система от нежно любимых вами файл-серверных СУБД? А практически ничем. В поздних версиях Клиппера, кстати, тоже SQL поддерживался.

Так что просьба отделять мух от котлет. Понятия клиент-сервер, язык запросов SQL, и 1С-Бухгалтерия просьба не путать. Возражения просьба излагать конкретно. Что не устраивает? Модель клиент-сервер? Язык SQL? Или конкретная реализация конкретного бухгалтерского пакета? И почему, "грабли где", и что предлагаем в качестве альтернативы.

Например:
"Клиент-сервер сосет для некой задачи Х а файл-сервер якобы рулит для этой задачи, и вот почему ..."

или

"Язык SQL сосет для некой задачи Y, а некий иной язык Z для этой задачи рулит, и вот почему ..."

А с недоношенными СУБД типа файлмэйкера уже ИМХО все предельно понятно. По крайней мере тем кто знает что такой обработка транзакций. с остальными в общем-то и спорить не о чем, ибо речь идет уже не о СУБД.
17 сен 04, 21:39    [970025]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
с недоношенными СУБД типа файлмэйкера

The original FileMaker was the Macintosh version of a similar database called Nutshell that was first written to run under DOS on IBM PCs and compatibles around 1982/1983.

все предельно понятно. По крайней мере тем кто знает что такой обработка транзакций

Да ничерта Вам не понятно. И ничего Вы не поймете пока не перестанете всё одним аршином мерить. На кой она здалась в ФМ эта Ваша "обработка транзакций"?! В ФМ %90 "бизнес логики" любой задачи можно реализовать на калькулируемых полях. Вспомните пример с иерархическим редактором, который я пириводил ранее. Здесь лежит PDF с распечаткой определений полей этого редактора. Определение полей, это - практически вся его, как Вы бы её назвали, "серверная часть". Никаких скриптов циклов и пр. в "серверной части" просто нет. Так вот, если Вы такой понятливый, то объясните мне п-ста как мне заменить всю эту массу калькулируемых полей "обработкой транзакций"? и главное зачем мне это делать?
18 сен 04, 15:00    [970441]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить