Скоро не бях писала.

Имам БД на MySQL, която съдържа поръчки. Релациите ги правих през phpMyadmin. Исках да станат 1:много:1. поръчка:данни за извършени дейности:извършил поръчката и уж се получи. Връзките са по номер на поръчката(между първите 2 таблици по реда записан горе) и по лицето, извършило дадена дейност(вторите 2 таблици). Искам към 1 поръчка да могат да се добавят много извършени дейности, като един човек от последната таблица да може да извършва от нито една до всички от тези дейности. Тук идва проблема. Когато въведа един и същ номер на поръчка в таблицата за извършените дейности, ми дава, че полето е "Primary key" и не може да има повтарящи се стойности. Същото е и ако въведа номер на човека, извършил дейността. Да, добре "Primary key" не може да съдържа повтарящи се стойности, но това ограничение не отпадали при връзка с много записи? Аз как да ги вържа по номер на поръчка тези таблици, ако полетата не са ключове? Проблемът ми в логиката на на връзване ли е или има шанс да не съм си създала правилно връзката? Малко заплетено стана, но исках да обясня подробно проблема. Благодаря, предварително.

Редактирано 7 август 201313 г. от ACCESS DENIED (преглед на промените)

Всеки primary key трябва да има уникална стойност. Когато правиш релация с друга таблица, стойността на primary key от основната таблица трябва да бъде вкарана като foreign key в другата таблица и чрез тази връзка да се направи релацията между двете таблици.

Редактирано 7 август 201313 г. от gothicrock (преглед на промените)

Здравейте !

 

Да, добре "Primary key" не може да съдържа повтарящи се стойности, но това ограничение не отпадали при връзка с много записи?

Не. Дефинирането на Primary Key е върху таблица, не върху връзка ! В случая, както Ви спомена gothicrock, връзката между таблици представлява Foreign key референция, намираща се в таблицата, стояща от страната на "много"-то на релацията. Този Foreign Key реферира стойност, измежду стойностите в Primary Key колоната на първата таблица (тази, която от страната на "едно"-то в релацията).

 

Аз как да ги вържа по номер на поръчка тези таблици, ако полетата не са ключове?

Втората таблица трябва да съдържа две Foreign Key колони, които да реферират Primary Key колоните съответно на поръчките и на поръчалите потребители. 

Една забележка: Двете въпросни колони може и да не са сами по себе си Primary Key колони и дори е желателно да не са.Таблицата за извършени дейности, освен да пази данни, има ролята и на свързваща релация на връзка "много:много" между поръчки и клиенти.

Проблемът ми в логиката на на връзване ли е или има шанс да не съм си създала правилно връзката?

Мисля, че истината е някъде по средата. По грешката, която Ви изписва, имам подозрение, че FK колоните в междинната таблица са нещо повече от такива (PK, може би ?!), което в случая е пречка. За по-конкретно предложение, къде евентуално е проблема, трябва да се разгледат DDL заявките към базата.

 

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

Едно нещо на ум - има много начини за дефиниране на FK, в зависимост от това, как да се държат записите при CRUD операции на реферираните данни - каскадно да се трият, да се зануляват или да се дава default стойност. За това имам предвид

 

Поздрави !

Редактирано 7 август 201313 г. от dpk (преглед на промените)

Да, прави сте. Аз намерих една статия, която ми помогна да се ориентирам. Не знам защо съм решила, че връзките се правят само по ключови полета и в двете таблици. То просто е невъзможно в моя случай. Благодаря и на двамата. Мисля, че ще оправя кашата.

Като тръгнах да си оправям мацаницата на връзките, се появи нов проблем. При опит да направя връзка не ми излиза прозореца за избор на изтриване и ъпдейт, а като изскачащ прозорец ми излиза празен прозорец(blank). Пробвах през друг браузър, пусках ъпдейти на браузъра. Типа на таблицата е InnoDB, който си поддържа връзки. Други решения във всеизвестния чичо не открих и затова ви питам дали сте имали подобен проблем?

Като тръгнах да си оправям мацаницата на връзките, се появи нов проблем. При опит да направя връзка не ми излиза прозореца за избор на изтриване и ъпдейт, а като изскачащ прозорец ми излиза празен прозорец(blank). Пробвах през друг браузър, пусках ъпдейти на браузъра. Типа на таблицата е InnoDB, който си поддържа връзки. Други решения във всеизвестния чичо не открих и затова ви питам дали сте имали подобен проблем?

За съжаление не съм попадал на подобни случаи, но пък и в работата рядко имам вземане-даване с базите данни, а още по-малко и с PHP   . Има ли начин да се провери в лога на браузъра или на самата база какво става (ако има такива логове, разбира се) ? Мисля, че пътя за решаване на този проблем започва от там ... Евентуално някакви ERROR или WARNING съобщения ...

 

Поздрави ! 

Редактирано 8 август 201313 г. от dpk (преглед на промените)

За съжаление не съм попадал на подобни случаи, но пък и в работата рядко имам вземане-даване с базите данни, а още по-малко и с PHP   . Има ли начин да се провери в лога на браузъра или на самата база какво става (ако има такива логове, разбира се) ? Мисля, че пътя за решаване на този проблем започва от там ... Евентуално някакви ERROR или WARNING съобщения ...

 

Поздрави ! 

Да, не се бях сетила да погледна там. В момента търся информация за проблема. Много благодаря.

 

Едит: Проблемът е решен.

 П.с. @dpk да кажа, че знам че само полетата могат да са ключове, не и връзките. Друго имах в предвид, но вече няма значение.

 

Редактирано 9 август 201313 г. от ACCESS DENIED (преглед на промените)

Едит: Проблемът е решен.

 П.с. @dpk да кажа, че знам че само полетата могат да са ключове, не и връзките. Друго имах в предвид, но вече няма значение.

 

Може би е ставало дума за това дали логическата връзка е имала нужда да се реализира чрез такива FK ? Ако е така, то отговорът е положителен за Вашия пример. Но щом всичко е тръгнало, смятаме проблема за решен .

 

Поздрави !

Може би е ставало дума за това дали логическата връзка е имала нужда да се реализира чрез такива FK ? Ако е така, то отговорът е положителен за Вашия пример. Но щом всичко е тръгнало, смятаме проблема за решен .

 

Поздрави !

Реших ключа на едната таблица да ми е нещо като индекс, който просто при всеки нов запис расте, обаче не знам точно как да го реализирам. В "Access" като му зададеш "Auto increment" и автоматично си ги генерираше тези индекси. Тук може ли да се реализира подобна логика? Полето съм го направила AI. Опитвам се да предам празна стойност към него, но не ми се получава явно. Празната стойност я предавам просто така ' '.

Реших ключа на едната таблица да ми е нещо като индекс, който просто при всеки нов запис расте, обаче не знам точно как да го реализирам. В "Access" като му зададеш "Auto increment" и автоматично си ги генерираше тези индекси. Тук може ли да се реализира подобна логика? Полето съм го направила AI. Опитвам се да предам празна стойност към него, но не ми се получава явно. Празната стойност я предавам просто така ' '.

Опитайте да направите запис, без да предавате никаква стойност за Auto Increment полето на кортежа, който ще запишете. Теоретично, СУБД-то на базата данни трябва да е генерирало вътрешна процедура по добавяне на такова ID, преди да запише реално данните. Тази процедура се изпълнява непосредствено преди запис автоматично и това става скрито от Вас. Това намерих в документацията на MySQL. Дано Ви помогне .

Опитайте да направите запис, без да предавате никаква стойност за Auto Increment полето на кортежа, който ще запишете. Теоретично, СУБД-то на базата данни трябва да е генерирало вътрешна процедура по добавяне на такова ID, преди да запише реално данните. Тази процедура се изпълнява непосредствено преди запис автоматично и това става скрито от Вас. Това намерих в документацията на MySQL. Дано Ви помогне .

Благодаря Ви. Проблемът не бил там обаче. Направих връзките, аналогично на тези. Обаче като се опитам да вкарам в registrations запис и гърми:

#1452 - Cannot add or update a child row: a foreign key constraint fails

Редактирано 13 август 201313 г. от ACCESS DENIED (преглед на промените)

Благодаря Ви. Проблемът не бил там обаче. Направих връзките, аналогично на тези. Обаче като се опитам да вкарам в registrations запис и гърми:

 

 

#1452 - Cannot add or update a child row: a foreign key constraint fails

Това имам подозрения, че се появява поради една от трите причини:

1) Опитвате се да въведете запис, за които полето doctorid има стойност, която не е налична в таблицата assigndoctor и по-точно в полето DoctorID

2) Опитвате се да въведете запис, за който полето patientid има сотйност, която не е налична в таблицата assignpatient и по-точно в полето PatienID

3) И 1) и 2)

 

Не изключвам възможността това да е страничен ефект от друг проблем, тък като тези ключове се генерират автоматично (съдейки по по-горните коментари).

Подозирам, че става следното: Опитвате се да запишете запис, който ще попълни и трите таблици. Тъй като таблиците с докторите и пациентите са с авто-инкрементален ключ, който се генерира при запис, то той още не е наличен, когато се прави записа в свързващата таблица. 

 

За да видим, че това е проблема, можем да изнесем самото запазване на данни в 2 транзакции - 1-вата ще запише данните за пациента и доктора, втората ще трябва да види какви са генерираните ИД-та за тях и ще запише правилните реферирани стойности във FK полетата (doctorid и patientid).

Това имам подозрения, че се появява поради една от трите причини:

1) Опитвате се да въведете запис, за които полето doctorid има стойност, която не е налична в таблицата assigndoctor и по-точно в полето DoctorID

2) Опитвате се да въведете запис, за който полето patientid има сотйност, която не е налична в таблицата assignpatient и по-точно в полето PatienID

3) И 1) и 2)

 

Не изключвам възможността това да е страничен ефект от друг проблем, тък като тези ключове се генерират автоматично (съдейки по по-горните коментари).

Подозирам, че става следното: Опитвате се да запишете запис, който ще попълни и трите таблици. Тъй като таблиците с докторите и пациентите са с авто-инкрементален ключ, който се генерира при запис, то той още не е наличен, когато се прави записа в свързващата таблица. 

 

За да видим, че това е проблема, можем да изнесем самото запазване на данни в 2 транзакции - 1-вата ще запише данните за пациента и доктора, втората ще трябва да види какви са генерираните ИД-та за тях и ще запише правилните реферирани стойности във FK полетата (doctorid и patientid).

Първо въвеждах при празни родителски таблици и се сетих, че просто няма с кой родителски запис да свържа новия, обаче като си въведох записи в родителските таблици, въпреки че въвеждам данни в подчинената таблица, които ги има в родителската получавам грешка #1452. Как да направя тези транзакции? Защото преди да се наложи да сменя ключа в подчинената таблица, нещата си вървяха и явно сега съм сгафила някъде при генерирането на FKs. Зададох ги като индекси в подчинената таблица през phpmyadmin.

Първо въвеждах при празни родителски таблици и се сетих, че просто няма с кой родителски запис да свържа новия, обаче като си въведох записи в родителските таблици, въпреки че въвеждам данни в подчинената таблица, които ги има в родителската получавам грешка #1452. Как да направя тези транзакции? Защото преди да се наложи да сменя ключа в подчинената таблица, нещата си вървяха и явно сега съм сгафила някъде при генерирането на FKs. Зададох ги като индекси в подчинената таблица през phpmyadmin.

Окей - това с транзакциите можем да го оставим засега, защото Вие вече имате попълнение данни за доктори и пациенти. Опитайте се да премахнете условието да са индекси в тази подчинена таблица - нека поне засега да са само един FK референции. Ако не се получи, премахнете FK contraint-ите и ги направете наново, но този път да са само FK референции - без индексиране или каскадни операции.

 

Надявам се това да помогне.

Редактирано 13 август 201313 г. от dpk (преглед на промените)

Окей - това с транзакциите можем да го оставим засега, защото Вие вече имате попълнение данни за доктори и пациенти. Опитайте се да премахнете условието да са индекси в тази подчинена таблица - нека поне засега да са само един FK референции. Ако не се получи, премахнете FK contraint-ите и ги направете наново, но този път да са само FK референции - без индексиране или каскадни операции.

 

Надявам се това да помогне.

Оправих се. Оказа се, че съм поразместила полетата из скрипта. Ако има награда за "пишман програмист" да ми я дават без номинации.   Благодаря Ви за помощта от сърце!

Оправих се. Оказа се, че съм поразместила полетата из скрипта. Ако има награда за "пишман програмист" да ми я дават без номинации.   Благодаря Ви за помощта от сърце!

Няма проблеми . Всичко сме правили такива или подобни изпълнения - важното е след тях да си вземем поука. 

 

Лек и спорен ден !