|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Сейчас есть таблица со следующими полями: id, name, description. И теперь надо связать эту таблицу с другими таблицами, вернее, другие таблицы надо будет связать с этой.
По полю name - связывать не можем, оно может меняться, тоже самое и с полем description. Делать связь по id - это же тоже не правильно. Значит необходимо вводить какое то новое дополнительное поле, правильно? которое будет нашим foreign key
Неактивен
А для чего по Вашему id?
Как раз очень хорошо подходит для связей.
Кстати можно делать связи по любому полю и даже по нескольким полям
Неактивен
ааа, тогда давайте уточним одну деталь. Сделали связь по name. Если я хочу изменить значение name - то оно мне даст это сделать? и будут ли автоматом сделаны замены в связных таблицах или же нет?
Неактивен
да, таки нельзя менять значение поля, если уже существуют связи. Значит утверждение:
"Кстати можно делать связи по любому полю и даже по нескольким полям" - в данном ситуации неверно.
Неактивен
Менять значение при наличии связи можно. Например, если отец меняет имя, то у детей отчество меняется автоматически; а вот если, ребенок хочет изменить отчество, то да, таки нельзя.
Про внешние ключи см FAQ №4.
Что же касается вашей ситуации, то широкой аудитории про неё ничего не известно, так как телепатия не входит в число наших достоинств 
Неактивен
я воспользовался ссылками приведенными в FAQ. Особенно детально изучил информацию приведенную тут: http://webew.ru/posts/219.webew
Однако у меня возник вопрос: в статье, в качестве примеров были созданы две таблицы:
CREATE TABLE customers (
userid INT NOT NULL UNIQUE KEY,
name VARCHAR(255) /* и т.п. */
) ENGINE = InnoDB;
CREATE TABLE orders (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
cid INT /* id покупателя */
/* и т.д. */
) ENGINE = InnoDB;
и установлена связь:
ALTER TABLE orders
ADD FOREIGN KEY (cid)
REFERENCES customers(userid)
ON UPDATE CASCADE
ON DELETE CASCADE ;
так вот у меня такой вопрос, почему поле customers.userid объявлено ИМЕННО КАК: NOT NULL UNIQUE KEY?
почему не использовано NOT NULL AUTO_INCREMENT PRIMARY KEY как для поля orders.id?
Неактивен
Хм. Я думаю, что Миша просто скопировал какие-то реальные таблички, а несущественные
для примера поля выкинул. Вот и получилось, что там UNIQUE 
Важно лишь чтобы был индекс на соответствующих полях в обеих табличках. PRIMARY в
случае InnoDB, разумеется, лучше.
Неактивен
ааа, хорошо, тогда что бы окончательно разобраться, скажите мне, пожалуйста, мы можем считать NOT NULL UNIQUE KEY равнозначным PRIMARY KEY?
ведь, PRIMARY KEY - это уникальный(UNIQUE) индекс, который не может быть пустым (NOT NULL), то есть в сумме получаем: PRIMARY KEY = NOT NULL UNIQUE KEY.
Единственное различие только в том, что PRIMARY KEY - один на всю таблицу, а UNIQUE KEY - сколько нам будет нужно (ограничение какое то есть не помню сколько). Я правильно все понял?
Неактивен
fenuk написал:
ааа, хорошо, тогда что бы окончательно разобраться, скажите мне, пожалуйста, мы можем считать NOT NULL UNIQUE KEY равнозначным PRIMARY KEY?
Нет. Например, только primary key может быть auto_increment.
Для innodb любой ключ, отличный от первичного, содержит указатель не на данные, а на значение первичного ключа.
Неактивен
vasya написал:
Нет.
Индексы PRIMARY KEY и UNIQUE подобны. Индекс PRIMARY KEY является индексом UNIQUE с именем PRIMARY. Это означает, что таблица может иметь только один индекс PRIMARY KEY, потому что двух индексов одной таблицы с одинаковым именем быть не может. Можно создать несколько индексов UNIQUE.
MySQL. Поль Дюбуа
Неактивен
Подобны и равнозначны - разные понятия.
Что же касается фразы "Индекс PRIMARY KEY является индексом UNIQUE с именем PRIMARY.", подозреваю, что это особенности перевода на русский
Неактивен
vasya написал:
Подобны и равнозначны - разные понятия.
Что же касается фразы "Индекс PRIMARY KEY является индексом UNIQUE с именем PRIMARY.", подозреваю, что это особенности перевода на русский
значит Воронина и Мартусенко - две гадины
Неактивен
На самом деле, Дюбуа прав отчасти, и переводчики нормальные
В случае MyISAM можно сказать, что PRIMARY — это действительно UNIQUE NOT NULL.
В случае с InnoDB у PRIMARY есть дополнительная особенность: это кластерный индекс.
Всё остальное является так или иначе следствием кластерности.
Неактивен
Ну, только PRIMARY может иметь атрибут auto_increment и его (PRIMARY) нельзя создать с помощью CREATE INDEX.
Я являюсь сторонником деления: PRIMARY, UNIQUE, non-UNIQUE, FULLTEXT..
"Министерство пропаганды" в этом со мной солидарно, выделяя PRIMARY в отдельный тип:
http://dev.mysql.com/doc/refman/5.1/en/mysql-indexes.html написал:
Most MySQL indexes (PRIMARY KEY, UNIQUE, INDEX, and FULLTEXT) are ..
Что же касается
fenuk написал:
vasya написал:
Что же касается фразы "Индекс PRIMARY KEY является индексом UNIQUE с именем PRIMARY.", подозреваю, что это особенности перевода на русский
значит Воронина и Мартусенко - две гадины
нехорошо беспричинно оскорблять людей. В том, что переводчики здесь не при чем легко убедиться открыв первоисточник:
http://reslib.com/book/27663
127 страница.
Неактивен
Ребята, спасибо за помощь.
vasya, спасибо за ссылку на http://reslib.com.
Неактивен
