Глобальная Авантюра  
ФОРУМ
главное меню
  1. >
  2. Форум >
  3. Научно-технический раздел >
  4. IT в России и мире в реалиях мирового кризиса

IT в России и мире в реалиях мирового кризиса

←Пред←1355356358359364→След→
 
  adolfus
   
   
adolfus  

Слушатель

Карма: +12.14
Регистрация: 12.02.2010
Сообщений: 6,479
Читатели: 2
 
Например MS SQL (вполне себе классическая реляционная СУБД), "на пальцах":
Параметр1=Таблица1.столбец1
Параметр2=Таблица1.столбец2
Таблица1.столбец3=Текст(Скуль Update над параметром 1 и 2(обновить Таблицу2.Строку3=Параметр1+Параметр2)
Испольнить
Параметр1=Таблица1.столбец1*3
Таблица1.столбец3=Текст(Скуль Update над параметром 1 и 2(обновить Таблицу2.Строку4=Параметр1-Параметр2+2)
Испольнить

Отношения между таблицей 1 и 2 выражены процедурой?
Сущности очень фундаментально статичны?
Данные изменяются сами по себе?
Вы, любезный, помнится несколько постов назад вообще уверяли:\n\n
Вы уж определитесь в какую сторону грести, пожалуйста.
Вы уже на первом "Параметр1=Таблица1.столбец1" вылетите по нехватке памяти.
Нельзя просто так копировать столбцы куда бы то ни было из базы, чтобы с ними что-то делать, даже если они помещаются, потому что их содержимое volatile по определению. Помимо Васи с БД работает Коля, Петя, Света и еще стопятьсот юзеров – в любой момент данные в столбце могут поменяться или исчезнуть. Это к тому, что "данные изменяются сами по себе".
В любой момент схема отношений и ограничений в базе может быть изменена независимо от вас (например, в связи с добавлением таблиц и столбцов, связанных вторичными инлдексами) и перестанет соответствовать вашей объектной модели.
Еще очень интересный момент – нет статичного соответствия типов между вашим ОО-языком программирования и типами в БД – в любой момент времени в базе данных тип может изменить представление, например после ее обновления. В результате однажды Вы при получении данных из базы в объект получите мусор или мусор запишете в БД.
-0.03 / 1
  slavae
   
   
slavae   Россия
Москва

Слушатель

Карма: +124.20
Регистрация: 21.03.2013
Сообщений: 18,901
Читатели: 4
 
в любой момент времени в базе данных тип может изменить представление, например после ее обновления. В результате однажды Вы при получении данных из базы в объект получите мусор или мусор запишете в БД.
Если базу курочит стадо обезьян, она и для хранения данных будет непригодна )
Империя - это мир, и этой идеологии достаточно. Мы живём в самой лучшей стране в мире и все нам завидуют.
Одушевлённое Одевают, Неодушевлённое Надевают.
+ 0.04 / 2
  DarkRaider
   
   
DarkRaider   Россия
Москва
39 лет

Слушатель

Карма: +7.25
Регистрация: 05.12.2016
Сообщений: 193
Читатели: 0
 
Вы уже на первом "Параметр1=Таблица1.столбец1" вылетите по нехватке памяти.
Нельзя просто так копировать столбцы куда бы то ни было из базы, чтобы с ними что-то делать, даже если они помещаются, потому что их содержимое volatile по определению.

Вы, любезный, очевидно, про реляционные БД и классический скуль только в учебнике читали и то мимоходом.
СУБД поддерживающие классический скуль - не работают целиком со столбцами, а поскольку объяснял я "на пальцах" и без синтаксиса - не упоминал идентификаторов строк, можете добавить с текст для себя [Таблица1.строка1.столбец1].
Если кому то интересна реализация динамического скуль запроса на MS SQL могу привести этот же пример с полным синтаксисом.

На досуге можете почитать про "колоночные СУБД" для общего развития.

Цитата
Помимо Васи с БД работает Коля, Петя, Света и еще стопятьсот юзеров – в любой момент данные в столбце могут поменяться или исчезнуть. Это к тому, что "данные изменяются сами по себе". В любой момент схема отношений и ограничений в базе может быть изменена независимо от вас (например, в связи с добавлением таблиц и столбцов, связанных вторичными инлдексами) и перестанет соответствовать вашей объектной модели.
Верно, именно для разрешения всех этих проблем и предназначена СУБД, для этого есть всякие блокировки, слепки и прочие механизмы неповреждающего обновления данных. Вот только данные меняются НЕ САМИ, а ПО КОМАНДЕ ОТ ДРУГОГО ПОЛЬЗОВАТЕЛЯ.
Для того чтобы не "переставало соответствовать" надо нормально учить уроки в школе и писать в коде не "SELECT * FROM ...", а "SELECT поле1,...полеN FROM ...". В таком случае изменение схемы данных путём добавления столбцов или их перемещения - никак на функционал не влияет. Приблизительно тоже самое и с внутренними связями, индексами, ограничениями.

Цитата
Еще очень интересный момент – нет статичного соответствия типов между вашим ОО-языком программирования и типами в БД – в любой момент времени в базе данных тип может изменить представление, например после ее обновления. В результате однажды Вы при получении данных из базы в объект получите мусор или мусор запишете в БД.
И тут, мой дорогой друг, Вы, сели в лужу, потому, что приведение типов тоже проходят в младшей программистской школе, ну по крайней мере раньше проходили, когда тёплое!=мягкому, но Вы не похожи на представителей молодого поколения. Таки в скуле оно есть. Кстати тип SQL_Variant тоже есть. Вы в очередной раз напрасно натягиваете сову на глобус пытаясь смешать процесс хранения данных с процессом их обработки в коде.

Данные хранятся и управляются на сервере,а скуль команды, Вы, ему задаёте на клиенте (приложение, служба, клиент командной строки) - а посему при нарушении схемы типов, сервер просто НЕ ВЫПОЛНИТ сбойную инструкцию и, Вы, как клиент, НЕ ПОЛУЧИТЕ ответ (будь то выборка данных или код успешного выполнения команды).
Сообщение скрыто автором
Отредактировано: DarkRaider - 21 сентября 2019 17:00:01
+ 0.04 / 3
  AndreyK-AV
   
   
AndreyK-AV   Россия
Уфа
58 лет

Слушатель

Карма: +62.55
Регистрация: 10.11.2008
Сообщений: 37,218
Читатели: 8
 

Первые 2000-е, звонок из Москвы - лети в Ноябрьск, они нам претензии выставили.
Я отвечаю что вы же Уфу отодвинули от договоров по транспорту с Сибнефтью, и там у вас манагер, у которого усё схвачено.
В ответ, манагер ушёл, а штраф и неустойки могут превысить контракт в несколько раз,
короче лети раз у вас там в Уфе центр внедрения и поддержки.
На вопрос, а разработчики?, ответ они не готовы вести переговоры,
к тому же на них Ноябрьск жестко наехал по принципам написания программ под Oracle, дескать они не умеют, тупые и отсталые, и вообще там экспертизу проводит живший и работавший в США и собаку съевший на Oracle и прикладных продуктах писанных по него. Короче наши закусились и ничего кроме срача у них не выйдет, к тому же главная претензия не чисто по их специализации.
ну и портянку высылают с перечнем претензий...
По Oracle пробежал, даже вникать не стал, так как уже лет пять серьезно не программировал, а программы для души, они делу не помогут..
Основное, это претензия в обмане заказчика, так как мы договоре прописали версию не ниже (емнип) 7.х.х., а сами написали ПО на 9.х.х. опять же емнип., при этом так что оно не работает, и диспетчера УТТ ждут отклика на нажатие клавиш от минуты до десятка, при этом время отклика должно исчисляться секундами максимум десятком...
Ну и портянка с описанием неправильного программирования....
Затем дополнительная вводная, оказывается на все наложился конфликт начальника управления А и его зама Р с главным инженером С который и затеял всю байду, и вместо попытки разобраться, подготовил претензию через главный оффис Сибнефти, и если она прокатит то полетит не только данный контракт, но и ряд других которые компания давно ведёт...
и если что, в компании всех собак спустят на Уфу, как ту её часть, что сперва поддержала разработчиков системы управления транспортом, затем начала продавать систему и создала группу внедрения и продвижения...
словом все плохо.
Прилетаю в Ноябрьск, едем в управление, там совещание где А, Р, С, чел из США А1, и пара руководителей смежных управлений из руководства УТТ, и кто то из головного офиса. Наехали сразу, А1 начал со своих многомиллионных работ в США, и затем жестко про неправильно написанную программу, на робкие возражения от УТТ, что дескать видели как работает в Мегионе, Надыме и нам такая система нужна..., жесткий ответ что и там сдохнет.
Затем С показал схему общей сети Сибнефти, о том что она сертифицирована Cisco и плохо работать не может, и перешёл к нарушению версий системы, дескать в договоре враньё и будем вас иметь как хотим, особенно за то что сразу не покаялись не вернули платежи и согласно предъяве не начали работу по правильному написанию ПО. Ну и раздухарился так что ещё сотню бакинских предложил накинуть за обман заказчика, и неча с ними разговаривать.....
Пришлось стать "оратором", с одной целью, посмотреть на месте как работает, тем более схема глобальной сети хоть и красива, но что внутри предприятий не описывала, а там по собственному опыту знаю что бывают такие "чудеса".
А и Р меня поддержали, как и представитель головной компании был не против подтвердить наше фиаско на месте, а у УТТ ничего и так не оставалось...
На следующий день поехали в Мупавленко. Приходим в УТТ, и оба на, в первом же коридоре, целые цепочки неуправляемых хабов... Потребовал составить акт и схему с описанием моделей устройств, после того как расписали второй десяток хабов, нашли линии витой пары длинной под триста метров... короче полный атас, и как там сеть работает вообще непонятно. Далее глухо висящий ПК с рабочим местом подсоединили напрямую к внешней сети Сибнефти и оба на, все резко залетало....
Обратно в Ноябрьск ехал со встречным актом и болванкой претензии об технической готовности УТТ к пилотному проекту.
В итоге свою претензию они отозвали, и вместо неё грозно потребовали исполнение договора, чтобы у нас всё на той версии Oracle что прописано работало, мы свою не предъявили, а подписали акт успешного окончания текущего этапа, на УТТ привели в порядок сеть, ну а спец по Oracle из США, так я его его больше и не видел, не пригласили его на дальнейшие переговоры...
"Не умирают гарибальдийцы, один упал, а два встают"
"Лучше умереть стоя, чем жить на коленях".
-------------------------------------------------------------
Наше дело правое. Враг будет разбит. Победа будет за нами.(с)
+ 0.21 / 15
   
Andrew Carleet   Канада
Flower City
53 года

Слушатель

Карма: +8.64
Регистрация: 13.07.2008
Сообщений: 1,665
Читатели: 5
 
Вы уже на первом "Параметр1=Таблица1.столбец1" вылетите по нехватке памяти.
Нельзя просто так копировать столбцы куда бы то ни было из базы, чтобы с ними что-то делать, даже если они помещаются, потому что их содержимое volatile по определению. Помимо Васи с БД работает Коля, Петя, Света и еще стопятьсот юзеров – в любой момент данные в столбце могут поменяться или исчезнуть. Это к тому, что "данные изменяются сами по себе".
В любой момент схема отношений и ограничений в базе может быть изменена независимо от вас (например, в связи с добавлением таблиц и столбцов, связанных вторичными инлдексами) и перестанет соответствовать вашей объектной модели.
Еще очень интересный момент – нет статичного соответствия типов между вашим ОО-языком программирования и типами в БД – в любой момент времени в базе данных тип может изменить представление, например после ее обновления. В результате однажды Вы при получении данных из базы в объект получите мусор или мусор запишете в БД.
Все в нашей жизни относительно.
Можно просто запереть данные, над которыми работаем, хоть поле, хоть всю базу. И данные в столбце не поменяются и не исчезнут "в любой момент". Так делать нехорошо? Ну, кто спорит; но подобное встрачается.

Любые изменения схемы/структуры базы данных делаются после модификации и тестирования всех приложений, использующих эту базу. Опять-таки, можно зафигачить ALTER в середине дня и без предупреждения. Но обычно так не делается. Нынче DBA тоже под ITIL ходят.
Отредактировано: Andrew Carleet - 24 сентября 2019 02:27:19
Никогда не думал, что буду жить во времена, когда Микки и Дональд правят в США (из интернета)

"Это при Советской Власти можно было работать для души." (ц) тёща Портоса.
+ 0.00 / 0
  adolfus
   
   
adolfus  

Слушатель

Карма: +12.14
Регистрация: 12.02.2010
Сообщений: 6,479
Читатели: 2
 
Все в нашей жизни относительно.
Можно просто запереть данные, над которыми работаем, хоть поле, хоть всю базу. И данные в столбце не поменяются и не исчезнут "в любой момент". Так делать нехорошо? Ну, кто спорит; но подобное встрачается.
Не встречается. СУБД не позволит.
Никто не может заблочить поле более, чем на некоторое небольшое время, достаточное на выполнение операции чтения актуального содержимого и записи обновления. Вы просто не видите того, что происходит под капотом. А под капотом происходит нечто, похожее на следующее:
1. Вы делаете запрос на получение каких-то полей
2. СУБД "делает" вам запись , отправляет ее вам и сохраняет копию (либо у себя, либо на клиенте)
3. Вы там что-то смотрите, колупаетесь, правите
4. Вы отправляете обновление
5. СУБД выполняет что-то, типа такого
- поля, которые Вы запрашивали, блокируются на запись (после Вашего доступа и до этого момента их мог изменить кто угодно)
- получаются актуальные значения полей, которые Вы выбрали
- выполняется сравнение полученных с полученными ранее из копии
- если идентичны, ваши изменения уходят в базу (профит), блоки снимаются.
- в противном случае блоки снимаются, вы получаете отказ, и измененные после вашего запроса поля актуализируются в копии и вашей записи. Внесенные Вами изменения аннулируются
Вы вынуждены перейти к цифре 3.
В результате продолжительность действия блокировки много меньше, чем продолжительность Вашего взаимодействия с базой.
Мало того, помимо тех таблиц, что Вы лично накриэйтили, СУБД создаст в Вашей БД таблицы учета статистики обращений, откуда она будет корректировать максимальные длительности блокировок для разных запросов, чтобы аварийно завершать транзакции, превысившие лимиты.


Вероятность того, что данные изменятся, может быть мала, но это не отменяет события, а с учетом законов Паркинсона, вероятность данного события может даже превысить число \pi.
Отредактировано: adolfus - 25 сентября 2019 14:43:59
-0.04 / 2
  Senya
   
   
Senya   Россия
50 лет

Слушатель

Карма: +181.20
Регистрация: 20.11.2008
Сообщений: 16,948
Читатели: 35

Глобальный Модератор
 
25.09.2019

Казанский квантовый центр Казанского национального исследовательского технического университета имени А. Н. Туполева — КАИ (ККЦ КНИТУ-КАИ), «Ростелеком» и «Таттелеком» успешно обеспечили обмен квантовыми ключами шифрования на волоконно-оптической линии связи (ВОЛС) протяженностью 143 километра, сообщает «Ростелеком».

По данным Казанского квантового центра КНИТУ-КАИ это мировой рекорд для действующих коммерческих сетей связи.

Ранее, в 2018 году, «Ростелеком» тестировал подобную технологию на ВОЛС протяженностью 58 километров.

В Татарстане тестовая ВОЛС соединила лабораторию Практической квантовой криптографии ККЦ КНИТУ-КАИ с узлом связи «Ростелекома» в Апастово. В тестировании были задействованы магистральные сети двух независимых операторов связи — «Ростелекома» и «Таттелекома», что важно для практического внедрения квантовых коммуникаций.

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

При тестировании работы криптомаршрутизатора были организованы сеансы видеоконференции между двумя узлами связи на расстоянии 143 километра с оптическими потерями в канале 37 дБ. Для обмена ключами шифрования использовался поток одиночных фотонов, в квантовые состояния которых записывалась классическая информация. Квантовая рассылка ключей проходила при частоте смены фазы модуляции 100 МГц со средним количеством фотонов 0,2 на один такт модуляции. Среднее значение скорости генерации квантовых ключей в канале позволяло менять 256-битный ключ шифрования до двух раз в минуту.

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

Источник
"Иван Грозный помещает на рабочий стол полученный от хана ярлык."(с) Не моё.
+ 0.14 / 9
  DarkRaider
   
   
DarkRaider   Россия
Москва
39 лет

Слушатель

Карма: +7.25
Регистрация: 05.12.2016
Сообщений: 193
Читатели: 0
 
Не встречается. СУБД не позволит.
Никто не может заблочить поле более, чем на некоторое небольшое время, достаточное на выполнение операции чтения актуального содержимого и записи обновления. Вы просто не видите того, что происходит под капотом. А под капотом происходит нечто, похожее на следующее:

Уважаемый, adolfus, уже становится забавным наблюдать полёт Вашей фантазии из головы, как в анекдоте про психолога и страшную жену ("... зато какие у неё кошмары!!!").

Цитата
1. Вы делаете запрос на получение каких-то полей
Таки после прочтения данных и отдачи результата действие СУБД на этом заканчивается. Операция атомарна - "прочитал на текущий момент времени".

Цитата
2. СУБД "делает" вам запись , отправляет ее вам и сохраняет копию (либо у себя, либо на клиенте)
3. Вы там что-то смотрите, колупаетесь, правите

Это Ваша персональная СУБД из головы делает Вам хорошо.

Цитата
4. Вы отправляете обновление
А вот это вторая операция "обновление". В зависимости от настроек базы она может быть атомарной одна или в группе, когда имеет место обновление нескольких связанных таблиц. Таблицы имеющие связи управляемые СУБД (ограничения, триггеры, связанные таблицы) - обновляются транзакционно. Так же режим транзакции легко включается вручную по мере надобности. Таковой режим позволяет объединить несколько операций чтения/записи в одну транзакцию, которая имеет свойства неделимости (атомарности) и общего результата (если выполнено успешно то всё, если ошибка где то - не выполнено ничего).


Цитата
5. СУБД выполняет что-то, типа такого
- поля, которые Вы запрашивали, блокируются на запись (после Вашего доступа и до этого момента их мог изменить кто угодно)
- получаются актуальные значения полей, которые Вы выбрали
- выполняется сравнение полученных с полученными ранее из копии
- если идентичны, ваши изменения уходят в базу (профит), блоки снимаются.
- в противном случае блоки снимаются, вы получаете отказ, и измененные после вашего запроса поля актуализируются в копии и вашей записи. Внесенные Вами изменения аннулируются
"горячечный бред", извиняюсь за мой французский.

Если поступает команда на ИЗМЕНЕНИЕ данных и нужная запись в данный момент заблокирована на запись другой сессией, команда встаёт в очередь и обновляет данные сразу после снятия первой блокировки.
Обновление данных - атомарно, если в момент физического обновления данных есть запрос на чтение - выдаются данные до вносимого изменения, до тех пор пока не будет подтверждено, что "данные изменены успешно". После этого на любой запрос будет выдаваться обновлённая информация.

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

Цитата
Вероятность того, что данные изменятся, может быть мала, но это не отменяет события, а с учетом законов Паркинсона, вероятность данного события может даже превысить число \pi.
Приятно, что, Вы, знакомы с "законами Паркинсона", хотя тут более уместны были бы "законы Мерфи".

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

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

Если использовать связи управляемые СУБД - она будет автоматически следить за синхронизацией этих данных и на чтение и на запись.
Сообщение скрыто автором
Отредактировано: DarkRaider - 27 сентября 2019 13:30:01
+ 0.11 / 7
   
Быдлокодер  

Слушатель

Карма: +1.39
Регистрация: 12.05.2017
Сообщений: 63
Читатели: 0
 
"с обоими не согласен" . Ну или согласен - как смотреть.

Во первых, вы пытаетесь описать уровень "изоляция образа", хотя несколько странно. Ну ладно.
Далее. Все изменения данных в РСУБД (и нет, Dbase III не СУБД) делаются в рамках транзакции. Транзакция не включается вручную, когда надо - она есть всегда. Другое дело, что у вас может быть выставлен автокоммит - это по транзакции на sql выражение - и он для программиста на Дельфи, наверно, выглядит как "нет транзакции" (не писал на дельфях - не знаю).
Далее. В случае изоляции образа СУБД гарантирует, что транзакция видит слепок закоммиченныз данных на момент начала транзакции. Т.е. она действительно записть "делает" - но это вопрос в какой момент. Если изоляция реализована на теневых записях (а это не обязательно), то просто читается старая версия записи.
Далее. Клиент меняет данные. Дисциплина блокировки зависит от стратегии разрешения конфликтов. Если пессимистическая (оракл), то СУБД блокирует запись, и другие транзакции, которые хотят запись изменить/заблокировать, будут ждать снятия лока. Если оптимистическая (firebird), то запись не блокируется, а при конфликте по изменению прилетит облом в момент коммита.
После изменения записи лок (если был) снимается не сразу, а по окончании транзакции. Это нужно для того, чтобы была возможность откатить текущую транзакцию на случай, если кто-то ещё до нашего коммита попытается поменять запись - т.е. чтобы исключить грязную запись. Ну и если у нас изоляция транзакций на блокировках, либо уровень изоляции выше изоляции образа - тогда и чтение другим блокируем - ну там нюансы, да.
Ну и не забываем про явные блокировки - select for update, или вообще lock table in exclusive mode.
Так что вполне можно заблокировать что-то на время жизни нашей транзакции - т.е. относительно надолго.

Ссылочная целостность уже навернута поверх этих механизмов - декларативно там, триггерами, уникальными индексами и т.д. Её может и не быть, и к предмету вашего спора она, по большому счету, не относится.
Сообщение скрыто автором
Отредактировано: Быдлокодер - 27 сентября 2019 16:15:01
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.00 / 0
  DarkRaider
   
   
DarkRaider   Россия
Москва
39 лет

Слушатель

Карма: +7.25
Регистрация: 05.12.2016
Сообщений: 193
Читатели: 0
 
"с обоими не согласен" . Ну или согласен - как смотреть.
"Люблю и ненавижу"(песенка модного ныне певцуна)?

Цитата
Если оптимистическая (firebird), то запись не блокируется, а при конфликте по изменению прилетит облом в момент коммита.
Просто какая то глобальная идея о вселенском обломе.

Оптимистическая блокировка не ограничивает модификацию обрабатываемых данных сторонними сессиями, однако перед началом предполагаемой модификации запрашивает значение некоторого выделенного атрибута каждой из строк данных (обычно используется наименование VERSION и целочисленный тип с начальным значением 0). Перед записью модификаций в базу данных перепроверяется значение выделенного атрибута, и если оно изменилось, то транзакция откатывается или применяются различные схемы разрешения коллизий. Если значение выделенного атрибута не изменилось — производится фиксация модификаций с одновременным изменением значения выделенного атрибута (например, инкрементом) для сигнализации другим сессиям о том, что данные изменились. by Википедия

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

Предлагаю желающим ознакомится с вики.
Тут виды блокировок.
А тут уровень изоляции транзакций
Странички небольшие и все варианты разруливания коллизий там описаны весьма конкретно. Так что изобретать не нужно.
Сообщение скрыто автором
+ 0.07 / 4
  dmitriк62
   
   
dmitriк62   Россия
Москва
57 лет

Слушатель

Карма: +160.72
Регистрация: 15.07.2009
Сообщений: 19,194
Читатели: 7
 
Скрытый текст

Про уровни транзисторов в кристалле процессоров или протоколы взаимодействия с оперативной памятью я молчу. Так до какого уровня должны программисты знать всё, чтобы не быть быдлокодерами?

До того самого уровня, который ещё знает пользователь Марк№76.
Глубже — совершенно бесполезные для программиста знания...
Многие пытаются смотреть, куда идёт дым.
А надо бы - откуда ветер дует.
-0.01 / 1
  slavae
   
   
slavae   Россия
Москва

Слушатель

Карма: +124.20
Регистрация: 21.03.2013
Сообщений: 18,901
Читатели: 4
 
Другое дело, что у вас может быть выставлен автокоммит - это по транзакции на sql выражение - и он для программиста на Дельфи, наверно, выглядит как "нет транзакции" (не писал на дельфях - не знаю).
"Домашний" сервер БД для Дельфи - Interbase, и уж это надо писать каким-то специальным образом, чтобы не знать, или не уметь управлять транзакциями на Интербейзе )
Сообщение скрыто автором
Империя - это мир, и этой идеологии достаточно. Мы живём в самой лучшей стране в мире и все нам завидуют.
Одушевлённое Одевают, Неодушевлённое Надевают.
+ 0.03 / 1
  СОВ
   
   
СОВ  

Слушатель

Карма: +0.06
Регистрация: 15.04.2018
Сообщений: 171
Читатели: 0
 
Это не работа, это жесть! Вручную обводить контуры этой бандурой - это ж свихнуться можно!
Посмотрите здесь с 19:40, для сложных пазов может быть идеальным вариантом:
+ 0.00 / 0
  slavae
   
   
slavae   Россия
Москва

Слушатель

Карма: +124.20
Регистрация: 21.03.2013
Сообщений: 18,901
Читатели: 4
 
Посмотрите здесь с 19:40, для сложных пазов может быть идеальным вариантом:
Я отрицаю любые работы, выполняемые вручную, это должны делать шаговые моторчики )
Империя - это мир, и этой идеологии достаточно. Мы живём в самой лучшей стране в мире и все нам завидуют.
Одушевлённое Одевают, Неодушевлённое Надевают.
+ 0.04 / 2
  adolfus
   
   
adolfus  

Слушатель

Карма: +12.14
Регистрация: 12.02.2010
Сообщений: 6,479
Читатели: 2
 
Посмотрите здесь с 19:40, для сложных пазов может быть идеальным вариантом:
HeARTwood. У него ролики о своих работах довольно интересные.
...
Таки клеят на поверхность репера. Точность наклейки определяет точность фрезерования.
Отредактировано: adolfus - 29 сентября 2019 23:41:44
+ 0.00 / 0
  СОВ
   
   
СОВ  

Слушатель

Карма: +0.06
Регистрация: 15.04.2018
Сообщений: 171
Читатели: 0
 
HeARTwood. У него ролики о своих работах довольно интересные.
...
Таки клеят на поверхность репера. Точность наклейки определяет точность фрезерования.
Ну нет, очевидно, что важна только неподвижность наклеек. К тому же на 20:29 видно, что оператор привязывает эскиз и к кромке заготовки (может, просто визуально совмещает, но благодаря оптическому увеличению и этого достаточно).
У меня сразу же идея в развитие этой появилась: использовать привязку по изображению заготовки, ведя съемку в трех масштабах - общий вид, крупно и микросъемка. Но т.к. автор изобретения не глупее меня, какие-то есть препятствия к такому подходу. Но лично у меня наклейки вызывают отторжение, я бы уж использовал радиомаяк+микросъемка (зеркальная поверхность редко бывает).
+ 0.00 / 0
  adolfus
   
   
adolfus  

Слушатель

Карма: +12.14
Регистрация: 12.02.2010
Сообщений: 6,479
Читатели: 2
 
Ну нет, очевидно, что важна только неподвижность наклеек. К тому же на 20:29 видно, что оператор привязывает эскиз и к кромке заготовки (может, просто визуально совмещает, но благодаря оптическому увеличению и этого достаточно).
У меня сразу же идея в развитие этой появилась: использовать привязку по изображению заготовки, ведя съемку в трех масштабах - общий вид, крупно и микросъемка. Но т.к. автор изобретения не глупее меня, какие-то есть препятствия к такому подходу. Но лично у меня наклейки вызывают отторжение, я бы уж использовал радиомаяк+микросъемка (зеркальная поверхность редко бывает).
Радиомаяк точности в 0.1 мм не даст.
Микросъемка даст скорость с некоторой погрешностью. Модуль той скорости порядка 1-2 см/с. Ее нужно интегрировать, как минимум, на пути порядка метр и получить положение фрезера с точностью не хуже 0.1 мм. Есть ли методы?
Отредактировано: adolfus - 02 октября 2019 17:24:45
+ 0.00 / 0
  slavae
   
   
slavae   Россия
Москва

Слушатель

Карма: +124.20
Регистрация: 21.03.2013
Сообщений: 18,901
Читатели: 4
 
Радиомаяк точности в 0.1 мм не даст.
Микросъемка даст скорость с некоторой погрешностью. Модуль той скорости порядка 12 см/с. Ее нужно интегрировать, как минимум, на пути порядка метр и получить положение фрезера с точностью не хуже 0.1 мм. Есть ли методы?
Шаговые двигатели и каретка на направляющих )
Сообщение скрыто автором
Империя - это мир, и этой идеологии достаточно. Мы живём в самой лучшей стране в мире и все нам завидуют.
Одушевлённое Одевают, Неодушевлённое Надевают.
+ 0.03 / 1
  СОВ
   
   
СОВ  

Слушатель

Карма: +0.06
Регистрация: 15.04.2018
Сообщений: 171
Читатели: 0
 
Шаговые двигатели и каретка на направляющих )
А могут эти шаговые двигатели помочь вырезать фигурные пазы под потолком готового помещения, или на косяках, под модные петли новых дверей, или красиво прорезать отверстия на старой мебели под светильник, например?
Представленное устройство имеет право на существование, оно способно выполнять уникальные операции, которые в противном случае может осуществить только мастер экстра класса.
+ 0.06 / 2
  СОВ
   
   
СОВ  

Слушатель

Карма: +0.06
Регистрация: 15.04.2018
Сообщений: 171
Читатели: 0
 
Радиомаяк точности в 0.1 мм не даст.
Микросъемка даст скорость с некоторой погрешностью. Модуль той скорости порядка 12 см/с. Ее нужно интегрировать, как минимум, на пути порядка метр и получить положение фрезера с точностью не хуже 0.1 мм. Есть ли методы?
Если радиомаяк будет давать точность в 5 мм, этого будет достаточно, т.к. под микросъемкой я подразумеваю съемку с большим разрешением примерно 1-го см2 поверхности. Т.е. мы просто запоминаем и впоследствии "узнаем" конкретный участок поверхности, а радиомаяк позволяет нам запоминать не всю поверхность, а только участок механической обработки. Визуальная же одометрия строится не на определении скорости смещения, а на непосредственном геометрическом определении изменения положения "распознанной" поверхности. Будет ли хватать для этого вычислительных мощностей? Если все делать "влоб", то может и не хватит, а если система будет адаптивно выбирать минимальный необходимый объем запоминаемой и обрабатываемой информации для однозначной привязки с заданной точностью, то думаю, все не так безнадежно.
Важно избежать рывков камеры нашего умного фрезера (хотя радиомаяк поможет быстро восстановить потерянное положение), а значит, он должен не скользить по рабочей поверхности, а катится на прорезиненных шариках, которые будут подтормаживаться с помощью магнитного поля. Ну это уже несущественные детали.
+ 0.00 / 0
загрузить следующие сообщения: 20 из 138
←Пред←1355356358359364→След→
 
НОВОСТИ ПАРТНЕРОВ

AFTERSHOCK

     
Сейчас на ветке:
Всего: 0, Гостей: 0, Пользователей: 0, Мобильных: 0
  1. >
  2. Форум >
  3. Научно-технический раздел >
  4. IT в России и мире в реалиях мирового кризиса
Глобальная Авантюра © 2007-2019 Глобальная Авантюра. Все права защищены и охраняются законом. При использовании любого материала любого автора с данного сайта в печатных или Интернет изданиях, ссылка на оригинал обязательна. Мнение администрации не обязательно совпадает с мнением авторов документов и комментариев, опубликованных на сайте.

CCBot/2.0 (https://commoncrawl.org/faq/)
Unknown

Яндекс.Метрика