powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Запутался с ключами
25 сообщений из 39, страница 1 из 2
Запутался с ключами
    #39240454
Алексей SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день! Дали задание создать таблицы по ER диаграмме. Немного запутался с ключами и с обеспечение целостности. Посмотрите пожалуйста правильно ли я сделал или можно оптимизировать.
В основном волнует таблица payment.

CREATE TABLE payment_type (
payment_type_id INTEGER NOT NULL PRIMARY KEY,
name VARCHAR(15) UNIQUE,
price_area NUMERIC(7,2),
price_people NUMERIC(7,2)

);

CREATE TABLE apartment (
apartment_id INTEGER NOT NULL PRIMARY KEY,
apartment_number SMALLINT,
house_number SMALLINT,
number_people SMALLINT,
area SMALLINT,
UNIQUE (apartment_number, house_number)
);

CREATE TABLE payment (
payment_type_id INTEGER NOT NULL REFERENCES payment_type(payment_type_id) ON DELETE RESTRICT ON UPDATE RESTRICT,
apartment_id INTEGER NOT NULL REFERENCES apartment(apartment_id) ON DELETE RESTRICT ON UPDATE RESTRICT,
m_y_date DATE,
summ NUMERIC(7,2),
payment_date DATE,
PRIMARY KEY(apartment_id, payment_type_id, m_y_date)
);
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240527
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей SQL,

Ну диаграмме база б.м. соответствует.
Я бы сказал что типы полей оставляют желать лучшего - номер дома это точно строка, а не целое (как Вы будете хранить номер дома "8/1"?), площадь квартиры - дробное число, а не целое, месяц и год с точки зрения целостности данных надежнее хранить 2 целыми числами с соответствующими ограничениями, а не датой ( сейчас Ваша база легко "проглотит" несколько платежей за один и тот же месяц-год )
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240633
Алексей SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Кот Матроскин,

так лучше? меня только волнует как в таблице payment CHECKнуть даты

CREATE TABLE payment_type (
payment_type_id INTEGER NOT NULL PRIMARY KEY,
name VARCHAR(15) NOT NULL UNIQUE,
price_area NUMERIC(7,2) NOT NULL CHECK (price_area > 0.00),
price_people NUMERIC(7,2) NOT NULL CHECK (price_people > 0.00)

);

CREATE TABLE apartment (
apartment_id INTEGER NOT NULL PRIMARY KEY,
apartment_number SMALLINT NOT NULL CHECK (apartment_number > 0),
house_number VARCHAR(7) NOT NULL,
number_people SMALLINT NOT NULL CHECK (number_people >= 0),
area NUMERIC(7,1) NOT NULL CHECK (area > 0.0),
UNIQUE (apartment_number, house_number)
);

CREATE TABLE payment (
apartment_id INTEGER NOT NULL REFERENCES apartment(apartment_id) ON DELETE RESTRICT ON UPDATE RESTRICT,
payment_type_id INTEGER NOT NULL REFERENCES payment_type(payment_type_id) ON DELETE RESTRICT ON UPDATE RESTRICT,
month_payment SMALLINT NOT NULL CHECK (month_payment > 0 and month_payment <= 12),
year_payment SMALLINT NOT NULL CHECK (year_payment > 1970 and year_payment <= 3000),
summ NUMERIC(7,2) NOT NULL CHECK (summ >= 0.00),
payment_date DATE NOT NULL,
PRIMARY KEY(apartment_id, payment_type_id, month_payment, year_payment)
);
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240678
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей SQLКот Матроскин,

так лучше? меня только волнует как в таблице payment CHECKнуть даты

CREATE TABLE payment_type (
payment_type_id INTEGER NOT NULL PRIMARY KEY,
name VARCHAR(15) NOT NULL UNIQUE,
price_area NUMERIC(7,2) NOT NULL CHECK (price_area > 0.00),
price_people NUMERIC(7,2) NOT NULL CHECK (price_people > 0.00)

);

CREATE TABLE apartment (
apartment_id INTEGER NOT NULL PRIMARY KEY,
apartment_number SMALLINT NOT NULL CHECK (apartment_number > 0),
house_number VARCHAR(7) NOT NULL,
number_people SMALLINT NOT NULL CHECK (number_people >= 0),
area NUMERIC(7,1) NOT NULL CHECK (area > 0.0),
UNIQUE (apartment_number, house_number)
);

CREATE TABLE payment (
apartment_id INTEGER NOT NULL REFERENCES apartment(apartment_id) ON DELETE RESTRICT ON UPDATE RESTRICT,
payment_type_id INTEGER NOT NULL REFERENCES payment_type(payment_type_id) ON DELETE RESTRICT ON UPDATE RESTRICT,
month_payment SMALLINT NOT NULL CHECK (month_payment > 0 and month_payment <= 12),
year_payment SMALLINT NOT NULL CHECK (year_payment > 1970 and year_payment <= 3000),
summ NUMERIC(7,2) NOT NULL CHECK (summ >= 0.00),
payment_date DATE NOT NULL,
PRIMARY KEY(apartment_id, payment_type_id, month_payment, year_payment)
);
У Вас много ошибок, схема БД совсем не соответствует диаграмме. "Таблицы" должны быть именно такие, как на диаграмме, а Вы начали что-то выдумывать, и добавлять элементы, не имеющие никакого смысла. Сделайте в точности так, как показано на диаграмме.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240683
Алексей SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Бредятина,

В условии задания сказано что диаграмму можно немного менять. Это не проблема, правильно ли сделаны ключи и все остальное?
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240705
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей SQLменя только волнует как в таблице payment CHECKнуть даты
Если в вашей субд есть функция типа isDate() (проверка даты на валидность) можете слепить строку из 01.month_payment.year_payment и проверить ее
Но вообще сама постановка - только один платеж в месяце выглядит бредово по-жизни.
>Мы не можем принять вашу оплату, так как вы уже платили в этом месяце
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240763
Алексей SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,

И еще такой вопрос, это разумно на все поля писать NOT NULL и делать CHECK каждого поля?
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240765
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей SQLБредятина,
В условии задания сказано что диаграмму можно немного менять. Это не проблема, правильно ли сделаны ключи и все остальное?
Вы написали сообщение в разделе "Проектирование баз данных". Базы данных так не проектируют. У Вас все неправильно. Есть условия задачи, и их незачем менять. У Вас три "таблицы":
Квартира {Номер дома; Номер квартиры; Площадь, Число жильцов}
Вид оплаты {Название; Цена за 1 м площади; Цена за 1 жильца}
Оплата {Период; Сумма; Дата оплаты}
Диаграмма - это и есть схема БД. Преподаватель просто решил проверить, понимаете ли Вы это, или не понимаете)))
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240767
Алексей SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Бредятина,

Вот условия задания:

Изучить ER-диаграмму, приведенную в вашем варианте индивидуального задания, при необходимости - модифицировать ее.
Заданная ER-диаграмма дает лишь ориентировочное представление о структуре данных заданной Вам предметной области, Вы можете модифицировать ее (но не в сторону упрощения!), добавив новые сущности, атрибуты, связи..
Конвертировать ER-диаграмму в концептуальную схему, отображаемую на реляционные таблицы, и нормализовать таблицы до формы не ниже Нормальной Формы Бойса-Кодда.
Составить SQL-скрипт для создания таблиц базы данных, включив в него все требуемые логикой предметной области декларативные ограничения целостности (первичные и внешние ключи, проверочные ограничения и т.п.)*1.
Утвердить результаты предварительной подготовки у преподавателя.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240777
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей SQLБредятина,

Вот условия задания:

Изучить ER-диаграмму, приведенную в вашем варианте индивидуального задания, при необходимости - модифицировать ее.
Заданная ER-диаграмма дает лишь ориентировочное представление о структуре данных заданной Вам предметной области, Вы можете модифицировать ее (но не в сторону упрощения!), добавив новые сущности, атрибуты, связи..
Конвертировать ER-диаграмму в концептуальную схему, отображаемую на реляционные таблицы, и нормализовать таблицы до формы не ниже Нормальной Формы Бойса-Кодда.
Составить SQL-скрипт для создания таблиц базы данных, включив в него все требуемые логикой предметной области декларативные ограничения целостности (первичные и внешние ключи, проверочные ограничения и т.п.)*1.
Утвердить результаты предварительной подготовки у преподавателя.
Вот, это другое дело! Очень хорошо. Значит у Вас задание не базу данных спроектировать, а реляционные таблицы. А обратиться с этой бедой больше некуда, а только в раздел "Проектирование баз данных".
Удачи Вам!
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240818
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей SQLНемного запутался с ключами и с обеспечение целостности. Посмотрите пожалуйста правильно ли я сделал или можно оптимизировать.
Ну сходу: очевидно, что в payment_type поле name должно быть not null, а из каждой пары price_area и price_people должно быть заполнено какое-либо одно. Кроме того, вешать на name unique нет никакого практического смысла - да, мысль понятна, но проблема в том, что unique ничуть не помешает внести в таблицу строки

Код: plaintext
1.
2.
3.
Горячая вода
ГОРЯЧАЯ ВОДА
Горячая  вода
ГВС

итп., поэтому такой constraint будет только напрасно тратить ресурсы. Аналогичных замечаний можно накидать и по другим таблицам. Кроме того, сама диаграмма напрочь неверная. Учёт оплат идёт по лицевым счетам, а лицевой счёт и квартира - это совершенно разные вещи. Чтобы проиллюстрировать это, проще всего упомянуть коммунальные квартиры.

Алексей SQLБредятина, В условии задания сказано что диаграмму можно немного менять.
Бредятина - это то, что осталось на форуме, когда отсюда лет восемь назад уехал большой цирк. Если не хотите читать несколько сотен страниц архивных топиков, чтобы понять, о чём он вообще говорит и почему он такой - лучше сосредоточьтесь на своей задаче.

Кот Матроскинмесяц и год с точки зрения целостности данных надежнее хранить 2 целыми числами с соответствующими ограничениями, а не датой
Не соглашусь; не стоит учить плохому. Ограничение уникальности на m_y_date пишется так же легко и просто, как и на "2 целых числа", зато последние приносят целый пласт уродств и ошибок при работе с данными. Достаточно написать запрос на просроченные оплаты - проведённые после 10-го числа следующего месяца - чтобы "прелесть" такого решения стала очевидной.

Алексей SQLИ еще такой вопрос, это разумно на все поля писать NOT NULL
Правильный подход - писать not null на все поля, где он нужен. В учебных задачах он нужен на подавляющем большинстве полей (вообще, по дефолту поле должно быть именно not null. когда точно поняли, зачем в этом поле null - убираем. и не раньше).

Алексей SQLи делать CHECK каждого поля?
В учебной задаче лучше сделать так, чем объяснять преподавателю, что не забыл об ограничениях.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240863
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerАлексей SQLНемного запутался с ключами и с обеспечение целостности. Посмотрите пожалуйста правильно ли я сделал или можно оптимизировать.
Ну сходу: очевидно, что в payment_type поле name должно быть not null, а из каждой пары price_area и price_people должно быть заполнено какое-либо одно.

Второе совершенно неочевидно - нет объективного закона, запрещающего вычислять стоимость услуги, исходя и из площади, и из числа жильцов (скажем, услуга "охрана придомовой территории" на это напрашивается). И когда управляющая компания
введет новую/изменит старую услугу таким образом, а программа этого не сможет "переварить" из-за взятого разработчиком с потолка ограничения...

softwarerКот Матроскинмесяц и год с точки зрения целостности данных надежнее хранить 2 целыми числами с соответствующими ограничениями, а не датой
Не соглашусь; не стоит учить плохому. Ограничение уникальности на m_y_date пишется так же легко и просто, как и на "2 целых числа", зато последние приносят целый пласт уродств и ошибок при работе с данными. Достаточно написать запрос на просроченные оплаты - проведённые после 10-го числа следующего месяца - чтобы "прелесть" такого решения стала очевидной.

"Соблюдать 1НФ - плохая практика и уродство данных" - это самая оригинальная точка зрения тут за последние года два :)
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240877
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин Второе совершенно неочевидно - нет объективного закона, запрещающего вычислять стоимость услуги, исходя и из площади, и из числа жильцов
Также нет объективного закона, запрещающего вычислять стоимость услуги, исходя из суммарного веса членов семьи (например, обслуживание лифта на это напрашивается), но в данных этот параметр почему-то не упоминается. Короче говоря, предлагаю не говорить глупостей. Если бьётесь за интересы управляющей компании, лучше уговорите топикстартера внести тариф по потреблению - за кубометр воды, киловатт-час электроэнергии и так далее, поскольку такие услуги и в самом деле нужно описывать.

Кот Матроскин "Соблюдать 1НФ - плохая практика и уродство данных" - это самая оригинальная точка зрения тут за последние года два :)
Повторяю предложение выше. Впрочем, с удовольствием посмотрю, как Вы уберёте эту точку зрения из собственных предложений и посоветуете топикстартеру разложить поля "название услуги", "номер дома" и прочие на атомарные буквы.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240917
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerКот Матроскин Второе совершенно неочевидно - нет объективного закона, запрещающего вычислять стоимость услуги, исходя и из площади, и из числа жильцов
Также нет объективного закона, запрещающего вычислять стоимость услуги, исходя из суммарного веса членов семьи (например, обслуживание лифта на это напрашивается), но в данных этот параметр почему-то не упоминается.

Вот именно. Поле "цена на жильца" упоминается, поле "цена на метр" упоминается, а ни соотношения между этими полями, ни "вес членов семьи" - не упоминаются. Поэтому надо не пороть взятую с потолка отсебятину, а отражать то, что есть в диаграмме - 2 поля безо всяких "заполнено может быть только одно".

softwarerКот Матроскин "Соблюдать 1НФ - плохая практика и уродство данных" - это самая оригинальная точка зрения тут за последние года два :)
Повторяю предложение выше. Впрочем, с удовольствием посмотрю, как Вы уберёте эту точку зрения из собственных предложений и посоветуете топикстартеру разложить поля "название услуги", "номер дома" и прочие на атомарные буквы.

А вот это уже не очень оригинально - почему (точнее, когда) буквы в строке не являются нарушением 1НФ, на этом форуме разбиралось.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240929
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей SQL,
Как видите, "прфессионалы" рекомендуют Вам оставаться на их уровне, чтобы была возможность, в крайнем случае, устроиться в большой цирк)) Если же Вы хотите понять что-то в области баз данных, читайте специально созданные для Вас общими усилиями учебные материалы (просто пропуская в них сообщения "профессионалов"). Например, здесь Вы можете найти основы проектирования БД:
http://www.sql.ru/forum/973198-65/db-specific-orm?hl=orm
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240934
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинПоэтому надо не пороть взятую с потолка отсебятину, а отражать то, что есть в диаграмме
Диаграмма допускает возможность указать все null-ы, то есть услугу вообще без цены. Вы, конечно, сейчас броситесь доказывать, что так и надо - флаг Вам в руки. Разработчик отличается от быдлокодера как раз тем, что правильно реагирует там, где последний тупо делает что ему дали так, как ему показали.

Кот МатроскинА вот это уже не очень оригинально
Безусловно. Пока что Ваши реплики не заслуживают оригинальных ответов.

Кот Матроскин- почему (точнее, когда) буквы в строке не являются нарушением 1НФ, на этом форуме разбиралось.
Верно. И точно так же день-месяц-год в дате не является нарушением 1НФ, тоже разбиралось и по тем же самым причинам.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240939
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerКот МатроскинПоэтому надо не пороть взятую с потолка отсебятину, а отражать то, что есть в диаграмме
Диаграмма допускает возможность указать все null-ы, то есть услугу вообще без цены. Вы, конечно, сейчас броситесь доказывать, что так и надо - флаг Вам в руки.

Т.е. Вы опять начинаете придумывать за меня тезисы и героически их опровергать?
Флаг Вам в руки(с) :)

.
softwarerКот Матроскин- почему (точнее, когда) буквы в строке не являются нарушением 1НФ, на этом форуме разбиралось.
Верно. И точно так же день-месяц-год в дате не является нарушением 1НФ, тоже разбиралось и по тем же самым причинам.

Если работа ведется с датой целиком (или со строкой целиком) - да, не являются. Проблема в том что "дата целиком " в Вашем предложении не несет никакой смысловой нагрузки, это просто контейнер для месяца-года. Точно так же как если название для целей форматирования добивать справа и слева пробелами, а потом из пробелов вычленять - это тоже будет нарушением 1НФ, хотя, казалось бы, символы в строке и ничего больше.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240943
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинТ.е. Вы опять начинаете придумывать за меня тезисы
"Надо делать как на диаграмме" - не Ваш тезис? Буду знать.

Кот МатроскинЕсли работа ведется с датой целиком (или со строкой целиком) - да, не являются.
Интересно, что Вы называете "целиком". Скажем, если запрос берёт из строки первые двести символов - это целиком или нарушение 1НФ? Если клиент выводит строку, в целях форматирования разбивая её на несколько по ширине - это целиком или нарушение 1НФ?

Кот МатроскинТочно так же как если название для целей форматирования добивать справа и слева пробелами, а потом из пробелов вычленять - это тоже будет нарушением 1НФ
И Вот мы как раз подошли к тому, что Вы предлагаете делать. Если бы прежде чем бросаться возражать, прочитали бы сказанное про просроченные оплаты - может быть не тратили бы ни моё, ни своё время.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240947
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerКот МатроскинЕсли работа ведется с датой целиком (или со строкой целиком) - да, не являются.
Интересно, что Вы называете "целиком". Скажем, если запрос берёт из строки первые двести символов - это целиком или нарушение 1НФ? Если клиент выводит строку, в целях форматирования разбивая её на несколько по ширине - это целиком или нарушение 1НФ?

Клиент может делать с полученными данными вообще все что угодно - мы обсуждаем базу, а не клиента.
А если запрос(ы) работают только с первыми 200 символами (в Вашем-то варианте работа ведется только с месяцем и годом, день не несет информации вообще) - ну таки да, я бы не назвал эту базу нормализованной.

softwarerКот МатроскинТочно так же как если название для целей форматирования добивать справа и слева пробелами, а потом из пробелов вычленять - это тоже будет нарушением 1НФ
И Вот мы как раз подошли к тому, что Вы предлагаете делать. Если бы прежде чем бросаться возражать, прочитали бы сказанное про просроченные оплаты - может быть не тратили бы ни моё, ни своё время.

*facepalm*
И что же откуда в базе я предлагаю вычленять ?
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240957
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаАлексей SQL,
Как видите, "прфессионалы" рекомендуют Вам оставаться на их уровне, чтобы была возможность, в крайнем случае, устроиться в большой цирк)) Если же Вы хотите понять что-то в области баз данных, читайте специально созданные для Вас общими усилиями учебные материалы (просто пропуская в них сообщения "профессионалов"). Например, здесь Вы можете найти основы проектирования БД:
http://www.sql.ru/forum/973198-65/db-specific-orm?hl=orm
Алексей SQL, если Вы будете читать "специально созданные для Вас общими усилиями учебные материалы", то Вы не останетесь на их ("прфессионалы") уровне, а опуститесь на несколько уровней ниже нуля.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39240970
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoБредятинаАлексей SQL,
Как видите, "прфессионалы" рекомендуют Вам оставаться на их уровне, чтобы была возможность, в крайнем случае, устроиться в большой цирк)) Если же Вы хотите понять что-то в области баз данных, читайте специально созданные для Вас общими усилиями учебные материалы (просто пропуская в них сообщения "профессионалов"). Например, здесь Вы можете найти основы проектирования БД:
http://www.sql.ru/forum/973198-65/db-specific-orm?hl=orm
Алексей SQL, если Вы будете читать "специально созданные для Вас общими усилиями учебные материалы", то Вы не останетесь на их ("прфессионалы") уровне, а опуститесь на несколько уровней ниже нуля.
Это самая суть! Как видите, Вас априори считают идиотом)))
...
Рейтинг: 0 / 0
Запутался с ключами
    #39241019
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаЭто самая суть! Как видите, Вас априори считают идиотом)))
А вроде на первый взгляд видно, что там считают редкостной ахинеей "специально созданные для Вас общими усилиями учебные материалы".
...
Рейтинг: 0 / 0
Запутался с ключами
    #39241778
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаАлексей SQL,
Как видите, "прфессионалы" рекомендуют Вам оставаться на их уровне, чтобы была возможность, в крайнем случае, устроиться в большой цирк)) Если же Вы хотите понять что-то в области баз данных, читайте специально созданные для Вас общими усилиями учебные материалы (просто пропуская в них сообщения "профессионалов"). Например, здесь Вы можете найти основы проектирования БД:
http://www.sql.ru/forum/973198-65/db-specific-orm?hl=orm
Я Вам рекомендую, для начала, использовать М2. Это Вам поможет намного глубже понять проблему "ключей" - в частности, и проблему "реляционной технологии" - в целом.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39242321
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей SQL, не всем рекомендациям, следует доверять. А некоторые, просто достойны игнорирования (например, если кто-то подбросит Вам что-нибуь с названием похожим на М2). Чтобы понять рациональное в ключах лучше конечно читать Теорию реляционных Баз данных Д.Мейера. Иначе есть риски принять за основное, что-то производное. Например, что ключи придуманы для идентификации. Тогда как, на самом деле, для уникальности, а уникальность позволяет их использовать в каких-то случаях для идентификации.
...
Рейтинг: 0 / 0
Запутался с ключами
    #39242695
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
)))))
...
Рейтинг: 0 / 0
25 сообщений из 39, страница 1 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Запутался с ключами
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]