Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Вобще начну с того что для таблиц я определил ключи первичный и тд. Теперь вопрос а зачем они нужны ? Вот пример есть таблица с организациаями, есть таблица с услугами и есть таблица с поставщиками услуг. В каждой организации разные услуги могут поставлятся разными поставщиками. Вот напримере этого можно объяснить зачем здесь ключи и практическая выгода от их использования.
MaximZaikinВобще начну с того что для таблиц я определил ключи первичный и тд. Теперь вопрос а зачем они нужны ? Вот пример есть таблица с организациаями, есть таблица с услугами и есть таблица с поставщиками услуг. В каждой организации разные услуги могут поставлятся разными поставщиками. Вот напримере этого можно объяснить зачем здесь ключи и практическая выгода от их использования.
Если честно, то я тоже этого не понимаю.
Но по всей видимости это идет из теории о нормализации таблиц а это в свою очередь базируется на математическом обосновании реляционной модели баз данных... Посмотрите соответствующие учебники - там это должно быть описано...
Неь ребята теорию я знаю. Ну более или менее. И литературы по этому делу у меня навалом. Просто я вот о чем подумал, вот например в этом случае как я привел ключи вобще не нужны тем более в FoxPro где я програмно могу отследить события и сформировать нужную реакцию программы. Но все же я чуствую что они очень нужны. Где вот рядом в осознании, но я пока не понял не увидел для чего они действительно мне нужны. Вот я ирешил об этом спросить у вас. Я попрежнему буду рад услышать ваши объяснения по этому поводу
Для обоснования необходимости ключей ответь на такие вопросы:
- Есть организация А, какие поставщики работали с этой организацией в прошлом году;
- Какие товары поставлял поставщик Б организации А;
- Сколько поставщиков поставляет товар С
Таких вопросов может быть много, и правильно спроектированная база данных это такая база, которая даст возможность найти ответ на каждый вопрос в виде набора команд SQL.
Такой подход описан в любой книге по проектированию базы данных.
если не использовать реляционную теорию и засунуть все данные в плоскую таблицу то ключи не нужны.
если использовать:
вероятно схемы БД такова
автор
-------------------------------------------------
видыУслуг
^
|
поставленныеУслуги-->поставщикиУслуг
|
V
организации
-------------------------------------------------
т.е. если у организации ключём является название (естественный ключ) то в таблице "поставленныеУслуги" хранится только название организации. Все данные об организации (например ИНН, юр.адрес и пр.) можно получить из таблицы "организации" найдя её по имени. В противном случае пришлось бы хранить эти данные для каждой поставленной услуги. И если какие-то данные об организации менялись то пришлось бы перепроверять всю таблицу "поставленныеУслуги", например услуга поставлялась организации ЧП Иванов с контактн.тел 12345 а теперь у них тел.54321.
можно так же использовать суррогатные ключи например rand() - это спасает от ситуаций когда естественный ключ меняется (на то он и естественный, было ЧП Иванов а стало ОАО Иванов).
это пример. В ряде случаев простой rand() подойдёт, во многих случаях нет. Так же как и название организации в качестве ключа в реальности использовать нецелесообразно.
