[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Класс работы с БД
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
dr.nomore
Теоретически так можно добавлять записи в связанные таблицы.

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

Ну вот, если теперь оборудовать инсерт упомянутой инструкцией, то строка с тем же менегером не вставится как новая запись, но обновиться, и, если оператор не накосячил при вставке/импорте, то инфа о менегере нипоцтрадает. Последний ид возвращается как обычно после вставки, на случай убдейта надо предварительно засунуть имя поля примари в аргумент ласт_инсерт_ид(ид).

Немного геморройно но реализуемо. Но только когда вы работаете с текстом. То есть когда имя менегера - обычный текст. Если это id менегера (ну, любой родительской записи) в списке имен менегеров, то оператор может выбрать только из тех менегеров, которые заведены в таблице менегеров, потому что список ему ничего другого выбрать не даст. Или валидатор в агенте обматерит оператора который умудрился импортить имя левого менегера.

И правильно сделает. Потому что культура пользования реляционной БД подразумевает именно такое поведение ПО работающего с реляционной БД. Иначе ПО будет называеться Ёкзель.
dr.nomore
Цитата (inpost @ 13.11.2013 - 07:03)
Ты видишь мой Primary key и предлагаешь его заменить на unique. Покажи MySQL структуру таблицы + код через ON DUPLICATE UPDATE, чтобы работал по этому unique ключу. Иначе мне сложно будет понять твою мысль.

http://dev.mysql.com/doc/refman/5.0/en/ins...-duplicate.html

Еще сложнее?

допустим поля а, б, в входят в составной уникальный ключ
поля г, д, е - не входят.

строится обычный запрос

insert into table (а, б, в, г, д, е) values( 1, 2, 3, 4, 5, 6)...


к которому добавляется инструкция


insert into table (а, б, в, г, д, е) values( 1, 2, 3, 4, 5, 6)
on duplicate key update
г = values(г),
д = values(д),
е = values(е);


примари уникальные или не примари - значения не имеет. СУБД составит ключ, обнаружит что такой уже е и вместо инсерта сделает убдейт.

Кстати, после убдейта affected_rows() дает 2, а не 1. По чему можно судить что произошло.

Насчет кода. Нашел в хламе. Ее давно уже нет, ничего не пишу я в конфиг, это оказалось лишним (сработала десктопная модель поначалу).

Метод висел на коннекте непосредственно, this - коннект. При создании инстанси другой метод доставал таблицу настроек и тупо копировал ее структуру в проперть settings, которая тупо stdClass. Ну вот, чтобы записать надо было взять эту структуру и заполнить ее values из аргументов метода. В общем сами разбирайтесь. В d[] копятся те самые рефы на значения полей которые надо обновить в случае нарушения уникальности ключа.

   	public function save_settings() {

if ($this->settings === 0) return 0;

$args = func_get_args();
$cnt = 0;

foreach($this->settings->fields as $key => &$value) {
if(isset($args[$cnt])) {
$value = $this->real_escape_string($args[$cnt]);
$d[] = '`' . $key . '` = VALUES(`' . $key . '`)';
}
else {
$value = null;
}
$cnt++;
}

$q = 'INSERT INTO `' . $this->settings->tb_name . '`';
$q .= ' (`' . implode('`, `', array_keys($this->settings->fields)) . '`)';
$q .= ' VALUES ("' . implode('","', $this->settings->fields) . '")';
$q .= ' ON DUPLICATE KEY UPDATE ';
$q .= implode(',', $d);
$q .= ';';

foreach($this->settings->fields as $key => &$value) {
$value = null;
}

if($res = $this->query($q))
return $this->affected_rows;

}
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.