Помогите пож студенту разобраться со странным противоречием в БД

Уважаемые гуру! На многих аналогичных форумах Украины я задал тот же вопрос. С чем я столкнулся?

Как такое может быть, что везде нам, студентам, навязывается непонятный ID в каждую таблицу? Зачем он мне, если все равно там будет присутствовать естественный ключ? А искусственный зачем? Это же мусор. Я просто не понимаю.

К примеру, ЭКЗАМЕН - все знают, что «оценку» за экзамен можно разыскать только благодаря конкатенации: "дисц+преподаватель+студент+курс+...+…".

И? Что мне даст "номер ведомости", если он будет сорить на винте? Или просто "номер записи"? Какая странная личность "внедрила" такой идиотизм в БД? Сколько лет он длится? И главное, если это длится больше 30 лет (мне так показалось), о каком корректным «датамайнинге» нам вешает лапшу преподаватель? О какой аналитике данных может идти речь при такой анти-математической дури?

Что нам с вами мешает выбирать коды всех сущностей только в соответствии с числом записей в таблице. И тогда все связи, как вот экзамен, также будут иметь естественный составной ключ исключительно пропорциональным совокупности всего «декартового произведения»?

Реально ничего не понимаю. Есть известный факт еще от Петера Чена (76 год вроде бы). В любой ПрО ВСЕГДА будут атомарные сущности (таких в жизни просто нет, но если вдруг найдутся, то в них только ID, здесь ничего не поделаешь), слабые сущности (в них уже конкатенация «наследников-предков» id1+id2+id3+…+idn) и составные сущности (они же связи – в них такие же конкатенации по структуре id1+id2+id3+…+idn).

А самое главное – такие структуры элементарно автоматизироваться на протяжении всего текста проги.

Да, можно сказать, что все такие совокупности частей ключей есть также ключ. Так дело не в том же! Они же будут и так присутствовать в таблицах, если вы будете проектироваться строго в соответствии с правилами Чена.

Как же вы спроектируете, например, таблицы «отдел», «кафедра», "факультет", "подразделение" или «квартира» без кодов предков?

Что вам скажет строка например «квартира номер 2007162003»? Это же полный идиотизм, если мы не знаем, что здесь 20 – это например город Одесса, 071 – это улица именно в этом городе, ну там… «Новосельского», 62 – это номер дома именно на ней (там вроде ПриватБанк находится, не помню точно, там еще Кирха есть), а уже 003 – номер квартиры .

Такие ID – уже все понятно, здесь нет недоразумений. А вот если он рандомный?

Какая проблема «тиражировать» структурированные коды, если всем давно от Петера Чена известно, что атомарных сущностей – просто не существует (ну или мизер, скажем, 1-2 на любой ПрО), слабых – примерно 50-60, не больше. А остальные – связи, то есть составные отглагольные существительные, как концерт, экзамен, митинг, запрос, заказ и т.д.

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

Простите пожалуйста, я не понял, зачем такая ерунда? Если вместо «рандомности» поставить кодировку содержания, все становится понятным. Неужели на протяжении этих многих лет никто это все не проанализировал? Вот никогда не поверю! Так подскажите пож!!

Где «оно» и почему его нет у наших преподавателей?

Так хто тобі забороняє зробити елементарний додаток для обліку студентів та екзаменів без використання ID? Покажи нам як це працює що усі не прави. А потім створи таку саму але з ID та приведи порівняльній аналіз.

Нічого не зрозумів. Хто такі "усі не праві"? Мене цікавлять дуже технологічні і конкрені питання.

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

Життя поребує постійної модифікації таких каскадів. От приміром, низова таблиця повязана з 4ма каскадами в кожному з яких по 2-3 а той навіть 5 таблиць. А ще існують звязки між каскадами, наприклад між 87ю, 96ю та 325ю таблицями. Як таке модулювати, якщо неможна (хто таке заборонив?) використовувати фрагменти ключів?

Та й ще не ясно. Як створювати конкретні звіти, якщо використувується такі дивні пари
25894756862 2002

Перше - це рандомний кей. А що тако друге? Рік, гроші, сума? Звідки брати інфу? Імям поля? А якщо таких полів - 1000, як тоді? Топтати клаву и втрачати зір до 30 років на щоденних модифікаціях прог? Та й дружину, оскільки ...

Що це за дурня?

Складені ключі - це математика, автомаизація та датамайнинг.
А рандомні що таке?

Мене цікавить конкретика - які інсруцмени підримують складені ключи автматично?

[QUOTE=Александр21;78076781]Нічого не зрозумів. Хто такі "усі не праві"? Мене цікавлять дуже технологічні і конкрені питання.

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

Життя поребує постійної модифікації таких каскадів. От приміром, низова таблиця повязана з 4ма каскадами в кожному з яких по 2-3 а той навіть 5 таблиць. А ще існують звязки між каскадами, наприклад між 87ю, 96ю та 325ю таблицями. Як таке модулювати, якщо неможна (хто таке заборонив?) використовувати фрагменти ключів?

Та й ще не ясно. Як створювати конкретні звіти, якщо використувується такі дивні пари
25894756862 2002

Перше - це рандомний кей. А що тако друге? Рік, гроші, сума? Звідки брати інфу? Імям поля? А якщо таких полів - 1000, як тоді? Топтати клаву и втрачати зір до 30 років на щоденних модифікаціях прог? Та й дружину, оскільки ...

Що це за дурня?

Складені ключі - це математика, автомаизація та датамайнинг.
А рандомні що таке?

Мене цікавить конкретика - які інсруцмени підримують складені ключи автматично?[/QUOTE]
От коли ти зрозумієш що я тобі написав та надаш конкретні приклади то буде відповідь, а зараз твої питання схожі на питання бота з котрим нема ніякого бажання спілкуватись.

Якщо нема чого сказати за суттю, переходять на особистості. Якого "бота"? Ти про що? Мені требо конкретна допомога, як моделювати каскади таблиць?

Не знаєшь? Так відверто і кажи. І не треба реагуватим на термін "гуру". Який же ти гуру, якщо не можеш конкретно допомогти.

Хоч матом крий мене, а проектування десятків каскдів твблиць - це потреба проектувння. Як їх моделювати?

Слабо тобі зізнатися, що просто це капкан для адішників? Відповідь "ніяк" тебе не влаштовує. От ти й лаєшся...

Боти... Дурня просто...

Вот студенты пошли, даже в гугл не умеют... :facepalm:
[URL="https://www.google.com/search?q=surrogate+vs+natural+primary+keys"]surrogate vs natural primary key[/URL]

P.S. Эта дискуссия стара как сама теория реляционных бд, давно уже наработаны best practices и рекомендации когда лучше использовать натуральный ключ, а когда искусственный, например: [URL="https://agiledata.org/essays/keys.html"]тынц[/URL]

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

Я задав дуже конкретне питання.

Математикам відомо, що ВСІ типи ПрО є системами. Системи мають певні математичні ознаки - структура, зв’язки, замкненість, функціонування й т.і. Зауважте, абсолютно всі типи "під-базиданових" ПрО - це виключно системи.

А тому "напрацьовувати" щось потрібно не думками-пропозиціями практиків, а після того - рекламою і інвестиціями в ці думки, а ТЕОРЕМАМИ. Строгими доказаними теоремами, якими колись було пронизане наукове середовище в РБД.

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

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

Все. От і вся дискусія. От тільки вчитель помер, і пошук цих теорем - ніяк.

Зрозумійте мене - ще тоді, років 30 тому, було нема про що дискутувати й нема про навіщо "напрацьовувати" (іншими словами, нав’язувати свої інструментальні засобі й підходи)

Структура ПрО (яка не залежить від часу або пренебрежно мало залежить від часу) - це завжди слабкі сутності (відділи, лабораторії, підрозділи, ділянки, вулиці, міста, квартири й т.і.). Існує теорема про каскади таблиць. Зміст її саме в тім, що слабкі сутності моделюються тільки каскадами таблиць. А отже структурами ключів виду A, A+B, A+B+C, A+B+C+D, ... Про що дискутувати? Треба просто не лінитися програмувати і нічого не підміняти

А події в ПрО моделюються виключно складеними сутностями (зв’язками, віддієслівними іменниками - концерти, іспити, замовлення, поставки, мітинги, угоди й т.і.), що залежать ще й від часу. Проте вони ще й повністю залежать ВИКЛЮЧНО від структури ПрО. Тому й тут структурі ключа нікуди дітися - виключно така сама. Адже якщо інша, втратяться зв’язки. У нас немає можливості віднайти оцінку за іспит 10 років тому без використання повного комплекту незалежних компонентів структури ПрО "Університет". Додадуться лише ознаки часу - дати. Все.

Я запитав не про "бізнесові та деякі напрацювання", а саме про теореми.

Настав час ДатаМайнингу. А це - математика. Приміром, дифури. Так от робота с коректними математичними таблицями, а тому математичні методи строгого однозначного (без дискусій) проектування ключів таблиць - це потреба часу.

Прошу допомоги і розуміння