[решено] Отсутствует ID, SQLQuery как сохранять?

[resident]

И сомневаюсь что phpadmin обновит корректно 2 одинаковые записи без id

У него ж уникальный ключ на эти поля, база не даст создать одинаковые записи.

[vitaly_l]

база не даст создать одинаковые записи.

Да. И + я это проверяю перед заполнением.


.

[resident]

Я писал исключительно про mysql

Ок

Беспалатный при самосборке из исходников.

Такие сложности я не осилю.

Почему нельзя редактировать в гридах? Я там редактирую...

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

[vitaly_l]

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

Какая же у Вас вредная кошка(кот), вот у меня собака была, она так не вредничала. Она понимала, что по клаве, ходить нельзя.
Однако, это довольно ВАЖНАЯ мелочь, которую можно априори предусмотреть и при желании включать или отключать.

Если есть ещё вкусные "конфекты", то насыпайте в этот топик, пригодятся всем.
Одна голова хорошо, а + к ней, знания 1000 мудрых программистов лучше. Спасибо.


.

[debi12345]

Такие сложности я не осилю

Под какую "ось" нужен SQLite Cypher и куда выложить бинарники ?
(могу попытаться собрать )

[resident]

Под какую "ось" нужен SQLite Cypher и куда выложить бинарники ?
(могу попытаться собрать )

Кхе, да я из любопытства спрашивал, что Снег Север ответит. Меня просто зацепило, что возможности, обсуждаемые с начала этой темы он назвал "гланды через ж". Но по моему на клиентском наборе элементарно сделать шифрование через потоки. Но клиентский набор использует только возможности здесь обсуждаемые и ничего не знает про SQL.
Вот и стало интересно, что же предложит любитель SQL с 8+ стажем в качестве шифрования локальной базы, чтоб без гланд и не через ж. Он увильнул от ответа: "Я писал исключительно про mysql. Для других БД могут быть другие приемы действенны."
Ваш же ответ только доказывает, что клиентский набор и обсуждаемые возможности имеют право на существование.
Реально сейчас у меня нет необходимости ни в локальной базе, ни в её шифровании. Благодарствую

[DYUMON]

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

[vitaly_l]

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

Это ЯВНО к уникальным ключам не относится. Зарплату можно удесятерить и с уникальным ключом и без него...
А таблицы без уникальных ключей, это с моей точки зрения норма, ДАЖЕ, если строки 100% совпадают по значениям.
(при условии что их ненужно редактировать)

.

Добавлено спустя 33 минуты 44 секунды:
Попробовал, сделать таблицу без ключа с 4-мя одинаково заполненными значениями.
При смене цифры в одной строке, меняется вся колонка с такими же значениями, а не одна строка.
Так что, DYUMON, в какой-то степени прав (если кому понадобится), но это не сбой это правило.


.

[Снег Север]

Вот и стало интересно

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

[vitaly_l]

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

Снег Север, расскажи интересно! Хочу знать, это очень полезная информация. Я честно зашифрую все передаваемые данные.

[debi12345]

Я честно зашифрую все передаваемые данные.

БД-сервера сами не шифруют траффик (чы з йуха йим цэ робыты ? ) - для это они полагаются на щифрование каналов связи (через VPN, SSH, IPSec и. т.п), но могут опознавать что канал шифруется - чтобы проверять прописанные в настройках БД-сервера правила аутенификации - например режектить коннекты от тех адесов-юзеров и к тем БД, к которым разрешен только зашифрованный коннект, в случае если приходит незащищенный коннект.

Вот кое-то из доки на Постгрес:

17.8. Возможности шифрования

PostgreSQL обеспечивает шифрование на разных уровнях и даёт гибкость в выборе средств защиты данных в случае кражи сервера, от недобросовестных администраторов или в небезопасных сетях. Шифрование может также требоваться для защиты конфиденциальных данных, например, медицинских сведений или финансовых транзакций.
Шифрование хранимых паролей
По умолчанию, пароли пользователей базы данных хранятся в виде хешей MD5, так что даже администратор не может определить, какой именно пароль имеет пользователь. Если шифрование MD5 также применяется при проверке подлинности, пароли не присутствуют на сервере в открытом виде даже кратковременно, так как клиент вычисляет и передаёт по сети только хеши паролей.
Шифрование избранных колонок
Модуль pgcrypto позволяет хранить в зашифрованном виде избранные поля. Это полезно, если ценность представляют только некоторые данные. Чтобы прочитать эти поля, клиент передаёт дешифрующий ключ, сервер расшифровывает данные и выдаёт их клиенту.
Расшифрованные данные и ключ дешифрования находятся на сервере в процессе расшифровывания и передачи данных. Именно в этот момент данные и ключи могут быть перехвачены тем, кто имеет полный доступ к серверу баз данных, например, системным администратором.
Шифрование раздела данных
Шифрование хранилища данных можно реализовать на уровне файловой системы или на уровне блоков. В Linux можно воспользоваться шифрованными файловыми системами eCryptfs и EncFS, а во FreeBSD есть PEFS. Шифрование всего диска на блочном уровне в Linux можно организовать, используя dm-crypt + LUKS, а во FreeBSD — модули GEOM, geli и gbde. Подобные возможности есть и во многих других операционных системах, включая Windows.
Этот механизм не позволяет читать незашифрованные данные с дисков в случае кражи дисков или всего компьютера. При этом он не защищает данные от чтения, когда эта файловая система смонтирована, так как на смонтированном устройстве операционная система видит все данные в незашифрованном виде. Однако, чтобы смонтировать файловую систему, нужно передать операционной системе ключ (иногда он хранится где-то на компьютере, который выполняет монтирование).
Шифрование паролей при передаче по сети
Метод проверки подлинности с MD5 дважды шифрует пароль на стороне клиента, прежде чем передать его серверу. Сначала вычисляется хеш MD5 пароля вместе с именем пользователя, а затем этот хеш обрабатывается ещё раз с добавлением случайного числа, переданного сервером при попытке подключиться к нему. Затем это дважды хешированное значение передаётся серверу по сети. Двойное хеширование не только позволяет защититься от вычисления исходного пароля, но и не даёт использовать тот же зашифрованный пароль при следующем подключении.
Шифрование данных при передаче по сети
SSL-соединения шифруют все данные, передаваемые по сети: пароль, запросы и возвращаемые данные. Файл pg_hba.conf позволяет администраторам указать, для каких узлов будут разрешены незашифрованные соединения (host), а для каких будет требоваться SSL (hostssl). Кроме того, и на стороне клиента можно разрешить подключения к серверам только с SSL. Для шифрования трафика также можно применять stunnel и SSH.
Проверка подлинности сервера SSL
И клиент, и сервер могут проверять подлинность друг друга по сертификатам SSL. Это требует дополнительной настройки на каждой стороне, но даёт более надёжную гарантию подлинности, чем обычные пароли. С такой защитой подставной компьютер не сможет представлять из себя сервер с целью получить пароли клиентов. Она также предотвращает атаки с посредником ("man in the middle"), когда компьютер между клиентом и сервером представляется сервером и незаметно передаёт все запросы и данные между клиентом и подлинным сервером.

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

[Снег Север]

Снег Север, расскажи интересно!

Так рассказывать особенно нечего - всё в документации описано: http://www.mysql.ru/docs/man/Miscellane ... tions.html
функции ENCODE и DECODE

[resident]

Вообще-то локальная и серверная БД - это две большие разницы

Зациклились на MySQL. Никакой разницы между серверной и локальной, если пользоваться приемами обновления обсуждаемыми в этой теме.

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

По второму кругу ни о чем. Если уж на то пошло, здесь форум про Лазарус, а не:

Похоже, мы о разном говорим. Я с MySQL работаю из Делфи и с ENGINE MyISAM

Вот кое-то из доки на Постгрес

Получается, что ничего из пункта "Шифрование данных при передаче по сети" Лазарус из коробки не поддерживает?
Да и пункт "Шифрование паролей при передаче по сети" тоже не про коробочный Лазарус?

[debi12345]

Шифрование данных при передаче по сети" Лазарус из коробки не поддерживает?

Вероятно через Indi-компоненты под OpenSSL?

[vitaly_l]

функции ENCODE и DECODE

Н-да... не густо. Это от кого шифрование? От сис. админов завтрашней смены?

Шифрование на стороне клиента

Более надёжная штука, но и это не 100% гарантия, даже при SSL подлинности сервера, т.к. программисты слишком хорошо владеют доступом к чужим машинам, и делятся кодом взлома в открытом доступе.

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


.