Есть таблица: TB с тремя полями tb_1, tb_2, tb_3. Необходимо сделать такой запрос создания этой таблицы, при котором будет не возможно добавлять новые записи, в которых комбинация tb_2 и tb_3 уже встречались. Например, строка
NULL, 1,1 - добавлена
NULL, 1,2 - добавлена
NULL, 1,1 - отказ (см. первую строку)

Код

CREATE TABLE tbl (   field_1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY   field_2 INT,   field_3 INT,   UNIQUE (field_2, field_3) );

или

Код

CREATE TABLE tbl (   field_1 INT NOT NULL,   field_2 INT NOT NULL,   PRIMARY KEY(field_1, field_2) );

Во втором варианте поле обязано быть NOT NULL

Делаешь SELECT перед вставкой, с GROUP BY tb2 , tb3

Цитата

Делаешь SELECT перед вставкой, с GROUP BY tb2 , tb3

Mal Hack, и это я слышу от тебя??? Никогда бы не поверил...

GROUP BY - "тормозная" операция гораздо проще (и быстрее) поставить уникальный индекс / первичный ключ, который и будет обеспечивать требуемую уникальность без всяких дополнительных запросов. При попытке добавления неуникальной по данным полям записей произойдет ошибка, которую можно легко отловить через mysql_error() / mysql_errno()

Это сообщение отредактировал(а) Bikutoru - 15.8.2005, 13:07

Цитата(Bikutoru @ 15.8.2005, 14:06)

Mal Hack, и это я слышу от тебя??? Никогда бы не поверил...

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

Bikutoru

Код

CREATE TABLE tbl (       field_1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY       field_2 INT,       field_3 INT,       UNIQUE (field_2, field_3)     );

Ведь в этом случае не возможно будет сделать следующие запросы:

Код

INSERT INTO tbl VALUE (NULL, 1,1) - пройдет INSERT INTO tbl VALUE (NULL, 1,2) - не пройдет, так как field_2, тоже должно быть уникальным

, а должно быть

Код

INSERT INTO tbl VALUE (NULL, 1,1) - пройдет INSERT INTO tbl VALUE (NULL, 1,2) - пройдет INSERT INTO tbl VALUE (NULL, 2,1) - пройдет INSERT INTO tbl VALUE (NULL, 1,2) - не пройдет, так как см. 2 строка

Суть: в данном контексте
field_1 - id строки
field_2 - id user
field_3 - id группы

Пользователь может принадлежать нескольким группам, но не может принадлежать одной группе дважды (в целях экономии места БД, да и просто чистоты). Реализовать это на PHP - можно и не сложно, однако, если операции с базой будет контролировать SQL - это гораздо удобнее, безопаснее и т.д. При относительно "большом" проекте, можно вполне где-то напутать с запросами, как мне кажется.

Цитата(slang @ 15.8.2005, 14:30)

Bikutoru CREATE TABLE tbl ( field_1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY field_2 INT, field_3 INT, UNIQUE (field_2, field_3) ); Ведь в этом случае не возможно будет сделать следующие запросы: INSERT INTO tbl VALUE (NULL, 1,1) - пройдет INSERT INTO tbl VALUE (NULL, 1,2) - не пройдет, так как field_2, тоже должно быть уника

slang, задам вопрос: "А ты проверял?" И сразу отвечу: "Нет". Ибо они нормально работают. А уникальность проверяется не по отдельным столбцам, а по их совокупности. Не веришь - проверь.


Mal Hack, по-моему, если есть возможность обеспечить целостность данных средствами СУБД, то лучше сделать это, а не прибегать к собственным ухищрениям, на которые другой программист, который будет работать с тем же проектом, может и наплевать...

Bikutoru
Извини, ты прав!!!
Сделал вывод используя не практическую проверку, а информацию из литературы и был НЕ прав.
Спасибо.

slang, пожалуйста, но в следующий раз проверяй прежде чем возражать, если не уверен

Цитата(Bikutoru @ 15.8.2005, 14:40)

если есть возможность обеспечить целостность данных средствами СУБД, то лучше сделать это,

Ошибка не есть целостность данных.

Цитата(Mal @ 15.8.2005, 15:07)

Ошибка не есть целостность данных.

А когда человек несумевший или незахотевший достаточно разобраться в твоем скрипте "забудет" об ограничении науникальность?.. Что тогда?

К тому же ошибка, возникающая при попытке добавления неуникального значения в поле unique, вполне узнаваема ("Duplicate entry '...' for key ...", код 1062).
К тому же, основываясь на одной логике, можно прийти к выводу, что попытка добавить неуникальное значение в уникальное поле - это ошибка в работе приложения и она тоже должна быть как-то обработана. Так что этот аргумент

Цитата(Mal @ 15.8.2005, 14:21)

ошибка она и есть ошибка, а следовательно, субъективно это нехорошо

отпадает. Дальше

Цитата(Mal @ 15.8.2005, 14:21)

я привык на ошибки откладывать только то, что говорит о том, что запрос не был выполнен

Это тоже не аргумент, т.к. запрос и не выполняется

P.S. Не хотел спорить, а заставляют...
Добавлено @ 14:50
К тому же контроль целостности на уровне сервера БД упрощает скрипт и разгружает сервер приложений. (Правда они могут быть и одним сервером, но это же частный случай )

Bikutoru тебе что выгоднее... Если упадет Апач или сервер БД?

Мне выгоднее, когда ничего не будет падать.
Но если нужно выбирать, то скорее сервер БД, ибо страницы я могу и закешировать ибрать из кеша, когда база лежит. А вот закешировать скрипты и брать их из базы... как-то слабо в это верится... А как это относится в теме дискуссии?

P.S. В "Религиозные войнЫ" тему!..
Добавлено @ 15:06
или в "Общие вопросы по БД"

Цитата(Bikutoru @ 15.8.2005, 16:04)

А как это относится в теме дискуссии?

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

Цитата(Mal @ 15.8.2005, 16:09)

Вообще на проектах всегда самое страшное когда БД упадет, т.к. в таком случае могут потеряться данные

Я думал, "упадет" в данном случае означает "временно откажется работать".
Можно же хранить информацию сразу на нескольких жестких (вроде бы, RAID-массив называется) тогда вероятность отказа из за неисправности HDD невелика, UPS и т.п. сводят такую вероятность к достаточно небольшому значению. Плюс регулярное копирование информации...
К тому же, при перегрузке СУБД (тот же MySQL) просто перестает обрабатывать вновь поступающие запросы...

Все-таки, по-моему, обеспечивать целостность скриптом, если можно базой не нужно...

Mal Hack, т.е. получается, что лучше большую часть работы с СУБД, производить средствами языка программирования, нежели средствами СУБД, чтобы нагрузка на СУБД была меньше, я правильно понял? Но тогда, зачем было давать такую возможность. Думаю, что создатели СУБД это приняли во внимание.

Цитата(Bikutoru @ 15.8.2005, 16:15)

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

Я так же думаю

Цитата(Bikutoru @ 15.8.2005, 16:15)

Можно же хранить информацию сразу на нескольких жестких (вроде бы, RAID-массив называется) тогда вероятность отказа из за неисправности HDD невелика, UPS и т.п. сводят такую вероятность к достаточно небольшому значению. Плюс регулярное копирование информации...

Это не совсем то, о чем я. Я имел ввиду, к примеру такую вещь, к примеру какой-ть глюк, к примеру из-за перегрузки. Сервер отказывается работать и как следствие не может скинуть в файл MYD данные, неаходящиеся в памяти.Как следствие данные теряются, еще хуже, если глюк происходит в момент записи этого файла. Все. Данные не вернешь, если MYD - битый. RAID конечно хорошо, но часть данных ты потеряешь, и можешь потерять целостность, к примеру в талицу с поставми пост нового пользователя добавился и сохранился, а на регистраци глюк и пара пользователей потерялась...

Цитата(Bikutoru @ 15.8.2005, 16:15)

Все-таки, по-моему, обеспечивать целостность скриптом, если можно базой не нужно...

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

Цитата(slang @ 15.8.2005, 16:39)

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

Да. Я считаю именно так.

Цитата(slang @ 15.8.2005, 16:39)

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

Какую возможность? Самому подставлять БД под ошибку? ИМХО это не возможность. Возможность использовать UNIQUE и в случае "дубляжа" получить ошибку? дык это правильно.
Т.е. возможность они дали, но это что-то вроде "последнего стража", как опять же МНЕ кажется.

Цитата

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

Это как минимум спорный вопрос. По-хорошему, его надо бы вынести в "Общие вопросы по базам данных"...