Шановні гуру! На багатьох аналогічних форумах України я задав теж саме запитання. З чим я зіткнувся? Як таке може бути, що скрізь нам, студентам, нав’язується незрозумілі ID в кожну таблицю? Навіщо він мені, якщо однаково там буде присутнім природній ключ? А штучний навіщо? То ж є сміття. Я не розумію просто. Приміром ІСПИТ - всі знають, що «оцінку» за іспит можна розшукати тільки завдяки конкатенації "дисц+викладач+студент+курс+...". 

І? Що мені дасть "номер відомості", якщо він буде смітити на вінті? Або просто "номер запису"? Яка дивна особистість "впровадила" таку дурню у БД? Скільки років триває такій ідіотизм? І головне, якщо це триває більше 30 років (мені так здалося), про якій коректний «дата-майнінг» нам вішає локшину викладач? Про яку аналітику даних може йти мова при такій анті-математичній дурні? 

Що нам з вами заважає  обирати коди всіх «ключових» сутностей тільки у відповідності до числа записів їх в таблиці. І тоді всі зв’язки, як от іспит, також буде мати природній сукупний ключ виключно пропорційним до сукупності всього «декартового добутку»? 

Реально, нічого не розумію. Є відома річ ще від Петера Чена (76 рік нвчеб то) – атомарні сутності (тут тільки ID, тут нічого не вдієш), слабкі сутності (тут вже конкатенація «наслідків-предків» id1+id2+id3+…+idn) та складені (зв’язки – тут такі ж самі конкатенації за структурою id1+id2+id3+…+idn). А саме головне – такі структури елементарно автоматизувати протягом всього тексту проги. 

Так, можна сказати, що всі такі сукупності ключів є також ключ. Так справа не в тім же! Вони будуть і так присутніми в таблицях, якщо ви будете проектувати строго у відповідності до правил Чена. Як же ви будете проектувати наприклад таблиці «відділ», «кафедра» або «квартиру» без кодів предків? 

Що нам скаже «квартира номер 2007180003»? Це ж повний ідіотизм, якщо ми не знаємо, що тут 20 – це приміром місто Полтава, 071 – це вулиця свме в цьомц місті, ну там… «Місячна», 80 – це номер дома саме на ній, а вже 003 – номер квартири. 

Такі ID – все норм, тут нема непорозумінь. А якщо він рандомний? Яка проблема «тиражувати» структуровані коди, якщо всім давно від Чена ще відомо, що атомарних сутностей – просто не існує (ну або мізер, скажімо, 1-2 на довільних ПрО), слабких – десь приміром 50-60, не більше. А решта – зв’язки, тобто складені віддієслівні іменники, як от концерт, іспит, мітинг, запит, замовлення й т.і. 

Зверніть увагу, саме такі структуровані ID одразу ж впишуться в математичність датамайнінгу. Хто нам заважає проектувати не бездумні придуркуваті рандомні ID, а суто змістовні, що строго моделюють діаграму Чена? 

Вибачте будь ласка, я не зрозумів, навіщо такі дурниці? Якщо замість «рандомності» поставити  кодування змісту, все стає зрозумілим. Невже за 30 років ніхто такого не запропонував? От ніколи не повірю! 

І де «воно» і чому його немає у наших викладачів?