Dmitry V. LiseevНе понимаю фразы "интерактивный ввод данных".
Почитайте Dmitry V. LiseevИ такого оператора представляю легко. Например, накладная приехала от внешней системы и "оператором" является модуль, который ее автоматически вводит в систему.А это называется "пакетный ввод данных" Dmitry V. Liseev В случае любого
сбоя вся транзакция должна откатиться.А масло называется маслом, потому что оно масляное Dmitry V. Liseev Точно так-же человек
у себя локально может набить все нужные позиции. Пусть
отрывается, пообедает, поспит, важно что в систему накладная
должна быть введена или вся целиком или вообще ничего.Совсем недавно Вы тут рассуждали о блокировках, я ничего не путаю? Хотя, проблема не только и не столько в них.
Dmitry V. LiseevЧего я передергиваю? Да, для чтения тоже такая проблема существует. Например, у меня есть права доступа. Юзер
может иметь запрет на операцию, разрешение на операцию.
Либо и то и другое, либо ни того ни другого. Юзер может
входить в несколько групп или ни в одну. Та группа тоже
может входить в несколько групп или ни в одну. То есть,
имеем ориентированный граф в общем случае с циклами,
но без контуров. Группы аналогично имеют булевый
флаг разрешения и булевый флаг запрета для каждой
из возможных операций. Это была дискреционная схема.
Есть еще мандатная. Каждый юзер и группа имеют уровень
допуска, а каждая строка таблицы - гриф секретности.Т.е., помимо того, что Вы предлагаете реализовать дополнительный слой (читай, внести некоторое количество ошибок) между клиентом и СУБД, Вы еще и собственную систему разграничения доступа реализуете? За все эти Ваши художества клиенты безропотно готовы платить? Стандартные, встроенные в приличные СУБД средства Вас не устраивают? Dmitry V. Liseev
А теперь вопрос, как выяснить с помощью всего одного SQL
запроса, можно ли юзеру в итоге выполнять операцию,
к примеру, на чтение строки в таблице или нельзя ее
выполнять? А делать это нужно для каждой строки каждой
таблицы, участвующей в транзакции. Если, к примеру,
при изменении кучи строк в транзакции мы на самой последней
строке нарываемся на запрет изменения, то вся транзакция
должна быть откачена.
Попробуйте почитать о
Fine Grained Access Control
Dmitry V. Liseev>...скажу только о том, что существуют СУБД, позволяющие
> отложить декларативную проверку целостности на конец транзакции.
А какая разница, в начале, в середине или в конце? Важно,
что внутри транзакции. Пока транзакция не завершена,
блокировки удерживаются. А когда транзакция завершилась,
то уже поздно что-то проверять.Вам в самом деле неинтересно, что те проблемы, которые Вы сами себе создаете и потом с успехом решаете, уже давно и надежно решены?
Dmitry V. LiseevТакие СУБД существуют, но толку пока мало. Хорошо, что Oracle об этом не знает Dmitry V. Liseev
Если перелопатив
кучу данных мы в самом конце узнаем, что нарушаем
целостность и транзакцию надо откатывать, то
производительности это не прибавляет. Какой смысл
начинать выполнять работу, если еще не известно, имеем
ли мы право ее выполнять? Да, можно начать выполнять, оценив
вероятность успешного завершения, как достаточно высокую.
Но это еще бабушка надвое сказала, сумеет ли планировщик
транзакций правильно предсказать. Процессоры Pentium тоже
умеют переходы предсказывать, только для них очень грамотный
специально заточенный компилятор требуется.Что такое планировщик транзакций? Вы имеете ввиду "менеджер транзакций"?
Dmitry V. Liseev
> И тут все наконец начинают понимать, что Вы пытаетесь
> проектировать системы с длинными транзакциями, а про то,
> что транзакции могут быть короткими, Вы вероятно не слышали.
> Пора в школу
Они у меня длинные просто по факту. По самой постановке
задачи. Пример с вводом накладной я уже приводил. Сложные
проверки логической целостности - еще один фактор влияющий
на количество операций внутри транзакции и ее длительность.
Пример с проверками прав доступа я только-что привел. И это
у меня еще цветочки.Постановка задачи может включить заголовок накладной и строки в одну транзакцию (см. ниже), но не может включать в себя требования по подробностям реализации (короткие/длинные транзакции), это мы уже обсуждали Dmitry V. Liseev
> Очевидность использования в приведенном примере длинной
> транзакции очевидна только Вам. Никто не мешает оформить
> сохранение накладной в виде:
> 1. Сохранение заголовка
> 2. Сохранение порций строк между, введенных после предыдущего
> сохранения.
> Транзакции при этом точечные и все надуманные Вами проблемы
> пропадают сами собой.
Согласен. Не очевидно. Тогда говорим прямое требование
заказчика. В накладной не должно быть только заголовка
или "порций". Либо все целиком, либо ничего. И уже из
этого требования вытекает очевидность использования
одной транзакции."Одна транзакция" <> "длинная транзакция".
Dmitry V. Liseev
> Так-так, ну ка, расскажите нам поподробнее о масштабировании,
> особенно в случае самописного сервера приложений, написанного
> на скриптовом языке, желательно в сравнении, скажем,
> с возможностями масштабирования Oracle 10g
Тут не топик. Масштабируется прекрасно. Именно по сравнению
с ораклом 10g. Как масштабировалась еще за годы до появления
первого оракла. Такова архитектура СУБД, что она изначально
создана под распределенную обработку данных на многих
дешевых серверах, а не на одном крутом SMP-сервере, как
оракл. Потому от одного компьютера, на котором и сервер
данных и сервер приложений и клиентская часть, можно без
особых затрат со временем дойти до конфигурации с десятками
удаленных друг от друга серверов и тысячами клиентов.Итак, Вы утверждаете, что
самописная скриптовая прослойка между клиентом и СУБД обеспечивает лучшие показатели производительности при росте количества активных пользователей и объемов базы, чем ведущие СУБД . Я ничего не перепутал и правильно понял Ваши слова? Dmitry V. Liseev> Измененный заказчиком функционал, обеспечивающий процессы
> заказчика у вас тоже на дистрибутиве?
Вы спросили "а если не отчет", я ответил, что если изменит ядро
системы, то его легко восстановить. За свой специфичный функционал
заказчик отвечает сам. Вы подтверждаете, что не занимаетесь поддержкой своего софта. Могу толко порадоваться за Вас
Dmitry V. LiseevЕсли заказчик ЕЖЕМЕСЯЧНО платит много денег
- мы берем ответственность и за поддержку его функционала. Однако,
такая модель бизнеса обычно не катит - очень дорого. Дело в том,
что мы вынуждены будем набирать на постоянную работу сотрудников,
которые будут решать мелкие проблемы этого заказчика раз в год-полгода,
но платить им надо ежемесячно. Спрашивается, зачем, если у заказчика
и так существует свой штат специалистов, которые получают
зарплату, работают там постоянно и хорошо знают специфику
своего предприятия? Существует инструмент по созданию
резервных копий не только данных, но и скриптов сервера
приложений. Выгрузил и положил диск в сейф. Если что-то
не работает - обратно поставили предыдущую рабочую версию.Гм. У заказчика имеются квалифицированные кадры, которые могут сопровождать чужую нетиражную систему? Расскажете, где Вы находите таких заказчиков? Dmitry V. LiseevСуществует тестовый сервер, на котором любые изменения
сначала обкатываются, а только потом идут в бой. Эта методика
описана в документации и заказчик с ней ознакомлен. И это
не мое изобретение. Так делают во многих сложных системах.А это Вы для чего рассказали? Полагаю, что большинство участников обсуждения знают о правилах разработки и внедрения нового функционала в работающую систему. Dmitry V. Liseev> Вы постоянно противоречите самому себе. То вы отдаете
> заказчику все в исходниках - правь-не хочу, то сначала
> заявляете, что заказчик не может написать ТЗ, но пишет
> требования. Вы уж определитесь сначала, какой именно
> линии собираетесь придерживаться в дискуссии
Не вижу противоречий. Написать в короткий срок ТЗ
на большую сложную систему масштаба "1C:Бухгалтерия"
действительно не может. Но вполне может высказать
отдельные требования. Добавить пару колонок в отчет
вполне может. Со временем разбирается и начинает
писать свои более сложные отчеты. Просто "написать
отчет" - это предметная область заказчика. Т.е., Вы абсолютно уверены в адекватности тех изменений, которые вносит IT-служба заказчика? Что у них никогда не возникнет, скажем, декартова произведения и сервер слегка просядет, выбирая миллиарды записей, после чего Вам выскажут много теплых слов о качестве Вашей разработки? Ах да, Вы уже говорили, что не занимаетесь поддержкой, да и разработкой тоже, все проблемы Ваших заказчиков будут решать простые разработчики Dmitry V. LiseevДаже я
не смогу написать отчет, пока месяца за полтора
в специфику заказчика не въеду."Даже я" - не слишком высокая самооценка?
Dmitry V. Liseev А "написать ТЗ" - уже
предметная область софтостроителей и тут как раз
заказчику надо будет познавать тонкости проектирования,
изготовления, доводки, обслуживания для софта и т.д.
(чуть не сказал "утилизации", слава богу, что хоть этого
в софтострении нет :) :)Ну да, ТЗ это же не требования, поэтому их должен писать... хм... тоже заказчик.
Попробую свести в кототенький список:
1. Заказчик формулирует требования в таком виде, что их можно реализовать, ничего не додумывая и не уточняя
2. По этим требованиям Заказчик (его IT-служба) разрабатывает функционал
3. Разработанный функционал внедряет Заказчик совмесно с Разработчиком, которым является IT-служба Заказчика
4. Поддержкой занимается кто? Правильно, опять Заказчик
В этом списке я не вижу какую прикладную задачу решаете лично Вы и разработчики Вашей фирмы. Просто продаете некий сервер приложений?
Зачем тогда рассуждать о жизненном цикле прикладных программ?
Может быть Вы приведете примеры успешных внедрений, тогда вопросы отпадут сами собой.
