[RomanRom2]

Сообщение от Ambal

могут погуглить - многа букаф

погуглил. а, вот как это называется

цитирую:

Из таких результатов я делаю следующий вывод: использование повсеместно запросов с prepared statements может замедлить работу с базой данных в полтора раза. Реальная выгода происходить только лишь при запуске подряд одинаковых запросов с разными параметрами. Также я вижу, что mysqlnd не совсем оправдывает ожидания. Как говорят разработчики, mysqlnd пришел заменить libmysql в связи с тем, что libmysql оптимизирована для работы с приложениями, написанными на С, а не PHP. И настоятельно предлагают использовать mysqlnd, потому что он оптимизирован для работы из PHP и по сравнению с libmysql имеет множество усовершенствований по работе с памятью и скоростью работы. Но, как мы можем наблюдать, mysqlnd все время проигрывает libmysql, хотя стоит заметить, что я не измерял используемую память и ресурс процессора. Это что касается производительности.

Что же с нашей безопасностью? Что лучше использовать prepared statements или real_escape_string? Многие говорят что real_escape_string это костыль, он что-то там недофильтровывает и всё такое. Я считаю, что он такой же костыль как и prepared statements , который не может подставлять переменные абсолютно во все места SQL запроса. Обычно логика вокруг real_escape_string такая же костыльная как и вокруг prepared statements , причём вокруг последних бывает побольше всякой хрени типа call_user_func_array. В связи с эти, я делаю следующий вывод: что безопасность, обеспечиваемая при использовании расширения mysqli, одинаково удобна, костыльна и "безопасна" как при real_escape_string так и при prepared statements . Другое дело использование prepared statements в PDO, где они поддерживаются на клиентской части и эмулируются, если сервер базы данных не поддерживает prepared statements . Слой абстракции PDO явно оправдывает подстановку параметров в запросы к разным СУБД.

http://itdumka.com.ua/index.php?cmd=shownode&node=17

или если не открывается:
http://hghltd.yandex.net/yandbtm?fmo...83d9b8&keyno=0

у себя такое тоже сделано, только я не заметил никакого прироста скорости, производительности и чего там еще ожидалось.

procedure DB_GetAccountInfo(var A: TAccount);
var
  DBResult: TMySQLResult;
  i: longint;
begin
  if not DataBase.Query('SELECT id, passw, access, UNIX_TIMESTAMP(game_prepaid), game_type, game_level FROM accounts WHERE login="%s"', [A.SecurityInfo.Login], QUERY_RESULT_STORE, DBResult) then
    begin
      MainLog('DB: ' + DataBase.GetLastError);
      Exit;
    end;

  if DBResult.Fetch then
    begin
      i:= 0;  A.AccountInfo.ID:=             StrToIntDef(DBResult.Field[i], 0);
      inc(i); A.SecurityInfo.Passw:=         DBResult.Field[i];
      inc(i); A.AccountInfo.Access:=         StrToIntDef(DBResult.Field[i], 0);
      inc(i); A.AccountInfo.PrepaidTime:=    StrToIntDef(DBResult.Field[i], 0);
      inc(i); A.AccountInfo.GameType:=       StrToIntDef(DBResult.Field[i], 0);
      inc(i); A.AccountInfo.GameLevel:=      StrToIntDef(DBResult.Field[i], 0);
    end;

  DBResult.Free;
end;
procedure DB_StoreSessionKey(var A: TAccount);
var
  i: longint;
  s: string;
begin
  for i:= 0 to 39 do 
    s:= s + IntToHex(A.SecurityInfo.Session[i], 2);

  if not DataBase.Query('UPDATE accounts SET session_key="%s", session_time=NOW() WHERE login="%s"', [s, A.SecurityInfo.Login]) then
    begin
      MainLog('DB: ' + strr(DataBase.GetLastErrNo)+ ', ' +DataBase.GetLastError);
      Exit;
    end;
end;