Бази даних полюбляю цю справу, але якось не дійшов до планування чого там?.. мг, перепрошую, а можна ширше розкрити поняття графічне планування БД, що це саме мається на увазі? та й коли воно доречне оць це графічне планування БД?
Наприклад, я б запропонував би хіба що такий варіант як форум, таблиця повідомлень така от,.. і вибірка з таблиць така от,... це наприклад, форум не реалізовував тому це лиш припущення.
Хоча напевно ж ще міг би припустити, графічне оформлення для реалізації БД, якщо скажімо інтернет-магазин..

Загалом, пане Esforeal, а для чого ви взагалі використовуєте графічне планування БД? та в чому його користь?

Якщо ви перейшли по посиланням, то могли б собі хоча б приблизно уявити. Прикріпив скріншот, подивіться.

Мені якось легше спланувати базу даних та зв’язки між ними, коли я їх можу просто намалювати (користуючись, наприклад, сайтами, на які я посилався). Та й код не потрібно набирати з нуля, графічно побудував базу - і "в путь" (експорт SQl, а потім імпорт у той же PhpMyAdmin чи ще куди).

Переглянув. Ні, тут немає графічної побудови, це не така програма.

Такі графічні інструменти потрібні, коли будуєте дуже складну архітектуру БД, або ви, скажімо, аналітик, який не хоче заглиблюватись в SQL, і якому треба сформулювати задачу для розробника БД.

На скільки я зрозумів, то це не ті випадки, і ви самі збираєтесь будувати відносно прості зв’язки між таблицями. В такому разі все ж краще не лінуватись і потроху вчитись самостійно це робити.

HeidiSQL справді є дуже зручним інструментом, але я не раджу використовувати його на продакті, бо у нього є хронічна дуже неприємна хвороба - при модифікації якогось існуючого об’єкта в БД (таблиці, процедури і т.д.) він може "упасти" не довівши справу до кінця, а це означає, що він може просто видалити об’єкт.

Таке трапляється дуже рідко, але трапляється. В інших аспектах він просто дуже зручний, має ітуїтивно-зрозумілий інтерфейс, не споживає багато ресурсів, вміє мабуть усе що необхідно в стандартних випадках: створення об’єктів БД, адміністрування, dump баз, написання запитів із підказками назв таблиць, функцій і т.д.

Головні правила Foreign Keys (зв’язків таблиць):
1. поля, які ви зв’язуєте повинні мати однаковий тип даних, однакову максимальну кількість символів, та однакове налаштування Unsigned (Unsigned вказуєте чи допускається значення менше нуля);
2. у полях дочірної таблиці, не повинно бути значень, яких немає у батьківської таблиці (якщо такі є, то їх спочатку треба видалити).

Якщо у вас у батьківській таблиці у полі ID є всього три значення: 1, 2, 3, то у дочірній таблиці не повинно бути будь-яких інших значень у тому полі, що посилається на ID батьківської таблиці. Причому ID може бути й не PK, а звичайне поле (не впевнений, але здається так).