Re: Временные таблицы 'on commit delete rows' и read-only транзакции
"Yakov Hrebtov" ... Нельзя ли разрешить изменения 'on commit delete rows'-таблиц в рамках RO-транзакции? На мой взгляд, это было бы полезно с практической точки зрения использования временных таблиц. Есть ли какие-то препятствия для реализации такой функциональности? Версионность в таких врем. таблицах теряет смысл. Понятно, что данные, находящиеся в 'on commit delete rows'-таблице принципиально не могут быть доступны другим транзакциям - БД после завершения транзакции гарантировано остается в неизменном виде, т.е. read-only фактически не нарушается. Кто что думает по этому поводу? :) (особенно разработчики) Обсуждали уже. Для GTT с ON COMMIT PRESERVE ROWS изоляция тр-ций нужна, делать пол-решения никто не будет. После 3.0 к этому вопросу обязательно вернёмся. Насчёт read-only тр-ций есть ещё несколько интересных\нужных фич, читайте fb-architect ;) -- Хорсун Влад PS http://tracker.firebirdsql.org/browse/CORE-1325
Re: Временные таблицы
Андрей Кручинин wrote: Эх. Жаль что гарантия обычно такая не устраивает. Хотя объем будет естественно маленький. По моим прикидкам не больше чем 50 тыщ записей, каждая из которых 2 поля максимум BIGINT. И эти люди что-то говорят об ужоре памяти и медленности загрузки im-memory-tables... Нет, если делать самому и как всегда, оно, конечно, можно и на тыще записей загнуться... -- Regards. Ded.
Re: Временные таблицы
On 13 дек, 20:33, имя wrote: > OM> тут ты знаешь имя файла, > OM> и как подсказал Влад, > OM> можешь попросить винду после перезагрузки - файл удалить > > Ага. Power Off, винт в другой комп. Зачем так грубо? Загрузочная флешка и все что надо на нее. Это быстрее и комп разбирать не надо. Метод проходит даже если тебя оставили на компе без присмотра на минут 15. Человек может даже и не знать на самом деле. Это даже не паранойя, а вполне реальный слив данных с чужого компа. Сам таким не занимаюсь, но сложного тут ничего не вижу. А в тех же аптеках, если заручится поддержкой начальника, тебе дадут сделать с компом все что душе угодно. Так что с точки зрения взлома этот способ слишком простой. И даже безпроблемный. Если я правильно понимаю, при постановке защиты надо учитывать все возможные способы взлома. То что неломаемых методов нет, это и козлу ясно кажется :-) Но тут надо иметь в уме следующие моменты: 1. В регионах найти человека достаточной квалификации достаточно сложно. О чем можно говорить если даже на обслуживание техники народ часто берет мальчиков с института. А более-менее квалифицораванные спецы едут в столицу на зашибание денег. 2. Рассчитывать стоит на то что данные будут взломаны и слиты. Именно поэтому надо сделать методику которая не даст взломщику доступа к данным даже если он ее поймет. 3. Ну и наконец я знаю как минимум пару человек с моего региона которые читают эту конференцию, а кроме того работают в этой же среде :-) И однозначно придеться закладываться на то что они прочитают и все это обсуждение :-) А вот обратятся к ним для хака или нет... Надеюсь что нет :-) В общем пока все тут писалось в голове родилось что-то очень похожее на симбиоз который ломануть наверное нереально будет в перспективе. Но подвязка, ясен пень, будет делаться на аппаратный ключ в совокупности со всякими другими методами. Надеюсь что скорость работы будет достаточно приемлемой :-) P.S. Ну и надеюсь наконец-таки что меня не оштрафуют за использование смайликов, только из-за того что данное обсуждение будет использоваться в перспективе в коммерческих целях. http://www.gravitron.ru/post_1229059713.html --- Андрей Кручинин
Re: Временные таблицы
> Ага. Power Off, винт в другой комп. > -- > Михаил. Слушай, если тебя _ТАК_ паранойя мучает, то сайт психотерапевтов не здесь. Или сам персобирай сырцы Firebird так, чтобы формат файла отличался от стандартного. Хочешь - тот же XOR примени, хочешь - truecrypt интегрируй - не так уж и сложно. З.Ы. Слушайте, я (напоминаю, Delphi-йский фундаметалист) тут недавно MS VC++ проникся... :) Забавная, однако, штуковина (с) Князь кивеский
Re: Временные таблицы
Oleg Matveyev пишет: OM> тут ты знаешь имя файла, OM> и как подсказал Влад, OM> можешь попросить винду после перезагрузки - файл удалить Ага. Power Off, винт в другой комп. -- Михаил.
Re: Временные таблицы
А чисто принципиально чем это отличается от временных таблиц? Тот же ресет и не спасет данные в базе. тут ты знаешь имя файла, и как подсказал Влад, можешь попросить винду после перезагрузки - файл удалить
Re: Временные таблицы
On 13 дек, 12:57, PEAKTOP wrote: > А ты в сторону CROSS-DATABASE запросов глянь. Пусть аппликуха при > старте создает TEMP.FDB с таблицами, индексами и прочей херней, а из > основной базы и делай запросы в TEMP.FDB. Естетсвенно, при выходе: > DROP DATABASE. > > Ну, это так, просто мысль. Может не подойдет. А чисто принципиально чем это отличается от временных таблиц? Тот же ресет и не спасет данные в базе. --- Андрей Кручинин
Re: Временные таблицы
> --- > Андрей Кручинин А ты в сторону CROSS-DATABASE запросов глянь. Пусть аппликуха при старте создает TEMP.FDB с таблицами, индексами и прочей херней, а из основной базы и делай запросы в TEMP.FDB. Естетсвенно, при выходе: DROP DATABASE. Ну, это так, просто мысль. Может не подойдет.
Re: Временные таблицы
On 12 дек, 13:19, Tonal wrote: > Андрей Кручинин пишет:> Собственно идея такая - защитить некоторые данные. > Делать защиту на > > сервере некузяво, использовать аппаратный ключ нереально (скорость не > > удовлетворяет однозначно). Поэтому идея в том чтобы клиентская машина > > брала с сервера блок защищенной информации и расворачивала на себе. > > А почему нельзя UDF-ку написать, которая расшифровывать будет? > Получится примерно всё то же самое, только трафик по сети гонять будет > не нужно. :) вопрос с UDF обоюдоострый. Дело в том что при использовании UDF придеться делать 2 функции - кодирования и декодирования. Потому как передавать на клиента данные придеться в открытом виде (точнее не закодированными именно сами данные которые потом придеться скрывать. причина в том что нагружать центральный сервер кодированием мне совсем не светит). А если в UDF есть 2 функции то даже думать как ломать не надо.Вызов можно отловить либо монитором, либо заглянуть в код ХП/ триггера или чего там еще. В случае же если я умудрюсь не передавать данные на сервер раскодированные (хотя хрен его знает как это получится. но задумка тут есть одна), то тогда все будет вообще классно. Но по поводу передачи данных на сервер тут оно понятно - лучше бы этого избежать. Что и буду пытаться делать. Заодно будет плевать и на временные таблицы тогда. --- Андрей Кручинин
Re: Временные таблицы
Андрей Кручинин пишет: Собственно идея такая - защитить некоторые данные. Делать защиту на сервере некузяво, использовать аппаратный ключ нереально (скорость не удовлетворяет однозначно). Поэтому идея в том чтобы клиентская машина брала с сервера блок защищенной информации и расворачивала на себе. А почему нельзя UDF-ку написать, которая расшифровывать будет? Получится примерно всё то же самое, только трафик по сети гонять будет не нужно. :)
Re: Временные таблицы
> > > В этом случае "кто помешает собрать сервер", который при старте > > смотрит в темп и чистит там свои временные файлы. > > Ну, в принципе никто не мешает встроить в FB возможность регистрации > вр.файлов в винде для их удаления в момент загрузки (есть такая системная > возможность), но как защититься от простого убиения процесса FB ? И тот, > кто в состоянии расколупать эти временные файлы на предмет наличия данных, > уж как-нить сможет сохранить их в целости :) Да собственно проблемы бы такой и не было если бы не одно "но" - мне нужно сохранить порядок данных. Это цена товара. Если я ее просто шифрану любым алгоритмом, то порядок полетит к черту. Если я ее шифрану, а потом на клиенте расшифрую в GTT то смогу работать спокойно. Но тут возникает вопрос что данные можно достать одним из 2х способов например. Есть еще некоторые мысли, но надо будет пробовать. Тут наверное придеться применять комбинированный метод, типа что-то в inmemory таблицах, что-то в GTT, плюс аппаратный ключ. В общем гемора пока видится много :-( Пока узкое место аппаратный ключ. Точнее скорость его работы. --- Андрей Кручинин
Re: Временные таблицы
по-моему он беспокоится, что временные файлы не самоудаляются при reset. Увы, это так В этом случае "кто помешает собрать сервер", который при старте смотрит в темп и чистит там свои временные файлы. Ну, в принципе никто не мешает встроить в FB возможность регистрации вр.файлов в винде для их удаления в момент загрузки (есть такая системная возможность), но как защититься от простого убиения процесса FB ? И тот, кто в состоянии расколупать эти временные файлы на предмет наличия данных, уж как-нить сможет сохранить их в целости :) -- Хорсун Влад
Re: Временные таблицы
Hello, Aleksey! Boulitchev Aleksey wrote: Тогда как насчет RAM-диска, на который настроен системный TEMP? Времянки сервер именно туда складывает. кто помешает собрать сервер, не уничтожающий за сосбой таблиц? по-моему он беспокоится, что временные файлы не самоудаляются при reset. В этом случае "кто помешает собрать сервер", который при старте смотрит в темп и чистит там свои временные файлы. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Временные таблицы
On 12 дек, 09:35, Alexey Voytsehovich wrote: > >> почему не inmemory tables? > > По мне чем изголяться с такими таблицами легче сделать один запрос и > > получить сразу нужные данные :-) > > лентяй. а еще о безопасности переживаешь ;) С ходу - сетевая работа. Клиент сидит на нетбуке. База в развернутом состоянии занимает порядка 100 метров, причем данные нужны с опредленной выборкой. т.е. все они единовременно не нужны. Тем не менее скорость нужна приемлемая. С inmemory я в свое время долбался, особенно с поиском. Ускорял. может надо было находить inmemory с индексами, но что-то мне подсказывает быстрее чем я делал врядли получится. И тем не мнее память этот поиск жрет прилично. В общем минусов больше чем плюсов. А безопасность Тут большого выигрыша не будет, да если надо кому, в крайнем случае и сервер перекомпилят. --- Андрей Кручинин
Re: Временные таблицы
On 12 дек, 10:53, "Khorsun Vlad" wrote: > >> Есть ограничения на внешние ключи между обычными таблицами и GTT, см. > >> релизные ноты. Кроме того, хоть индексы на GTT и работают, иногда можно > >> огрести сюрприз от оптимизатора, т.к. если индекс создан заранее (не по > >> "живым" данным), то его статистика, есс-но, нулевая. Насколько я помню, > >> если таблица типа PRESERVE, то SET STATISTICS сразу после заливки > >> позволяет решить этот вопрос. > > Угу, должно быть именно так. Ага, вот за статистику спасибо. Будем собирать :-) > >> Влад проснется - точнее скажет :-) > > Поспишь тут с вами :) Нефиг спать. Работать надо :-) > > > Эх, везет... Он еще спать может :-) > > Ну... смотря во сколько ложиться :) Да и время у вас не правильное, на час > вперед убегает :) Ну все как обычно, в 3-30 лег, в 6-30 встал Нормальный режим :-) Хорошо хоть днем можно поспать послав всех и вся. --- Андрей Кручинин
Re: Временные таблицы
On 12 дек, 10:26, "Boulitchev Aleksey" wrote: > кто помешает собрать сервер, не уничтожающий за сосбой таблиц? Никто не мешает. Разве только что отсутсвие квалификации у народа. Есть другие способы взлома такого скрытия :-) А то что по большей части народ тупой до ужаса. Или как у меня один знакомый их называет "50-ти рублевые мальчики" после которых только цены на обслуживание начинаешь поднимать, это я думаю даже рассказывать не надо :-) --- Андрей Кручинин
Re: Временные таблицы
On 12 дек, 09:55, Dmitry Yemanov wrote: > > Тогда как насчет RAM-диска, на который настроен системный TEMP? Времянки > сервер именно туда складывает. Тиражируемая программа :-( Ладно, покатит. Если больше подводных камней нет, меня и такая гарантия устроит. Не настолько там суперсекретные данные. Тем более их можно достать (пусть и не в полном объеме) другими способами будет :-) В крайнем случае распечатать. Главная фишка в том что нужно сделать так чтобы нельзя было скопировать базу и в ней получить нужные данные. --- Андрей Кручинин
Re: Временные таблицы
> 2. Нет ли каких-либо неудобств и подводных камней в использовании > временных таблиц совместно с остальными данными. Типа индексов и иже с > ним. Есть ограничения на внешние ключи между обычными таблицами и GTT, см. релизные ноты. Кроме того, хоть индексы на GTT и работают, иногда можно огрести сюрприз от оптимизатора, т.к. если индекс создан заранее (не по "живым" данным), то его статистика, есс-но, нулевая. Насколько я помню, если таблица типа PRESERVE, то SET STATISTICS сразу после заливки позволяет решить этот вопрос. Угу, должно быть именно так. Ок, гляну по этой теме что там висит. Влад проснется - точнее скажет :-) Поспишь тут с вами :) Эх, везет... Он еще спать может :-) Ну... смотря во сколько ложиться :) Да и время у вас не правильное, на час вперед убегает :) -- Хорсун Влад
Re: Временные таблицы
Тогда как насчет RAM-диска, на который настроен системный TEMP? Времянки сервер именно туда складывает. кто помешает собрать сервер, не уничтожающий за сосбой таблиц? -- Булычев Алексей http://www.stella-npf.ru
Re: Временные таблицы
Андрей Кручинин wrote: Эх. Жаль что гарантия обычно такая не устраивает. Тогда как насчет RAM-диска, на который настроен системный TEMP? Времянки сервер именно туда складывает. -- Дмитрий Еманов
Re: Временные таблицы
On 12 дек, 09:24, Dmitry Yemanov wrote: > Андрей Кручинин wrote: > > > 1. Влад как-то писал что файлы с временными таблицами удаляются сразу > > после ненужности (или после создания для линускоидов, но у меня винда, > > так что не сильно интересует этот вопрос :-) ) Но был вопрос про RESET > > системы. Что-то поменялось или проверялось? > > Думаю, как карта ляжет. Если размер таблицы небольшой, то есть > вероятность, что ОС вообще не сбросит таблицу из файлового кеша на диск, > так что после ресета в темпе будет пустой файл. Но гарантии тут никто не > даст, разумеется. Эх. Жаль что гарантия обычно такая не устраивает. Хотя объем будет естественно маленький. По моим прикидкам не больше чем 50 тыщ записей, каждая из которых 2 поля максимум BIGINT. > > > 2. Нет ли каких-либо неудобств и подводных камней в использовании > > временных таблиц совместно с остальными данными. Типа индексов и иже с > > ним. > > Есть ограничения на внешние ключи между обычными таблицами и GTT, см. > релизные ноты. Кроме того, хоть индексы на GTT и работают, иногда можно > огрести сюрприз от оптимизатора, т.к. если индекс создан заранее (не по > "живым" данным), то его статистика, есс-но, нулевая. Насколько я помню, > если таблица типа PRESERVE, то SET STATISTICS сразу после заливки > позволяет решить этот вопрос. Ок, гляну по этой теме что там висит. > Влад проснется - точнее скажет :-) Эх, везет... Он еще спать может :-) А тут до утра работаешь, а потом еще ехать надо к клиентам и ребенка в школу везти... правда в обратном порядке. И если еще первых можно послать, то ребенка надо оттаранить ко времени :-) (Сегодня почти проспали :-) ) --- Андрей Кручинин
Re: Временные таблицы
On 12 дек, 09:10, Alexey Voytsehovich wrote: > почему не inmemory tables? По мне чем изголяться с такими таблицами легче сделать один запрос и получить сразу нужные данные :-) Андрей Кручинин.
Re: Временные таблицы
Андрей Кручинин wrote: 1. Влад как-то писал что файлы с временными таблицами удаляются сразу после ненужности (или после создания для линускоидов, но у меня винда, так что не сильно интересует этот вопрос :-) ) Но был вопрос про RESET системы. Что-то поменялось или проверялось? Думаю, как карта ляжет. Если размер таблицы небольшой, то есть вероятность, что ОС вообще не сбросит таблицу из файлового кеша на диск, так что после ресета в темпе будет пустой файл. Но гарантии тут никто не даст, разумеется. 2. Нет ли каких-либо неудобств и подводных камней в использовании временных таблиц совместно с остальными данными. Типа индексов и иже с ним. Есть ограничения на внешние ключи между обычными таблицами и GTT, см. релизные ноты. Кроме того, хоть индексы на GTT и работают, иногда можно огрести сюрприз от оптимизатора, т.к. если индекс создан заранее (не по "живым" данным), то его статистика, есс-но, нулевая. Насколько я помню, если таблица типа PRESERVE, то SET STATISTICS сразу после заливки позволяет решить этот вопрос. Влад проснется - точнее скажет :-) -- Дмитрий Еманов
Re: Временные таблицы
Hello Андрей, Friday, December 12, 2008, 8:04:24 AM, you wrote: > HI ALL! > В свое время вопрос конечно поднимался, но интересно - не поменялось > ли что :-) почему не inmemory tables? -- Best regards, Alexey Voytsehovichmailto:iron...@gmail.com
