ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Запутался с ключами
39 сообщений из 39, показаны все 2 страниц
  все  
Запутался с ключами
    #39240454
Алексей SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей 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
20.05.2016, 21:44
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39240527
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Алексей SQL,

Ну диаграмме база б.м. соответствует.
Я бы сказал что типы полей оставляют желать лучшего - номер дома это точно строка, а не целое (как Вы будете хранить номер дома "8/1"?), площадь квартиры - дробное число, а не целое, месяц и год с точки зрения целостности данных надежнее хранить 2 целыми числами с соответствующими ограничениями, а не датой ( сейчас Ваша база легко "проглотит" несколько платежей за один и тот же месяц-год )
...
Рейтинг: 0 / 0
21.05.2016, 02:57
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39240633
Алексей SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей 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
21.05.2016, 12:53
| Ответить | Цитировать | Написать  
Запутался с ключами
    #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
21.05.2016, 14:53
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39240683
Алексей SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей SQL
Гость
Бредятина,

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

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

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

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

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

Изучить ER-диаграмму, приведенную в вашем варианте индивидуального задания, при необходимости - модифицировать ее.
Заданная ER-диаграмма дает лишь ориентировочное представление о структуре данных заданной Вам предметной области, Вы можете модифицировать ее (но не в сторону упрощения!), добавив новые сущности, атрибуты, связи..
Конвертировать ER-диаграмму в концептуальную схему, отображаемую на реляционные таблицы, и нормализовать таблицы до формы не ниже Нормальной Формы Бойса-Кодда.
Составить SQL-скрипт для создания таблиц базы данных, включив в него все требуемые логикой предметной области декларативные ограничения целостности (первичные и внешние ключи, проверочные ограничения и т.п.)*1.
Утвердить результаты предварительной подготовки у преподавателя.
Вот, это другое дело! Очень хорошо. Значит у Вас задание не базу данных спроектировать, а реляционные таблицы. А обратиться с этой бедой больше некуда, а только в раздел "Проектирование баз данных".
Удачи Вам!
...
Рейтинг: 0 / 0
21.05.2016, 21:39
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39240818
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
22.05.2016, 01:55
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39240863
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
softwarerАлексей SQLНемного запутался с ключами и с обеспечение целостности. Посмотрите пожалуйста правильно ли я сделал или можно оптимизировать.
Ну сходу: очевидно, что в payment_type поле name должно быть not null, а из каждой пары price_area и price_people должно быть заполнено какое-либо одно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*facepalm*
И что же откуда в базе я предлагаю вычленять ?
...
Рейтинг: 0 / 0
22.05.2016, 18:30
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39240957
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаАлексей SQL,
Как видите, "прфессионалы" рекомендуют Вам оставаться на их уровне, чтобы была возможность, в крайнем случае, устроиться в большой цирк)) Если же Вы хотите понять что-то в области баз данных, читайте специально созданные для Вас общими усилиями учебные материалы (просто пропуская в них сообщения "профессионалов"). Например, здесь Вы можете найти основы проектирования БД:
http://www.sql.ru/forum/973198-65/db-specific-orm?hl=orm
Алексей SQL, если Вы будете читать "специально созданные для Вас общими усилиями учебные материалы", то Вы не останетесь на их ("прфессионалы") уровне, а опуститесь на несколько уровней ниже нуля.
...
Рейтинг: 0 / 0
22.05.2016, 18:59
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39240970
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятинаАлексей SQL,
Как видите, "прфессионалы" рекомендуют Вам оставаться на их уровне, чтобы была возможность, в крайнем случае, устроиться в большой цирк)) Если же Вы хотите понять что-то в области баз данных, читайте специально созданные для Вас общими усилиями учебные материалы (просто пропуская в них сообщения "профессионалов"). Например, здесь Вы можете найти основы проектирования БД:
http://www.sql.ru/forum/973198-65/db-specific-orm?hl=orm
Алексей SQL, если Вы будете читать "специально созданные для Вас общими усилиями учебные материалы", то Вы не останетесь на их ("прфессионалы") уровне, а опуститесь на несколько уровней ниже нуля.
Это самая суть! Как видите, Вас априори считают идиотом)))
...
Рейтинг: 0 / 0
22.05.2016, 19:48
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39241019
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
БредятинаЭто самая суть! Как видите, Вас априори считают идиотом)))
А вроде на первый взгляд видно, что там считают редкостной ахинеей "специально созданные для Вас общими усилиями учебные материалы".
...
Рейтинг: 0 / 0
22.05.2016, 22:32
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39241778
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
БредятинаАлексей SQL,
Как видите, "прфессионалы" рекомендуют Вам оставаться на их уровне, чтобы была возможность, в крайнем случае, устроиться в большой цирк)) Если же Вы хотите понять что-то в области баз данных, читайте специально созданные для Вас общими усилиями учебные материалы (просто пропуская в них сообщения "профессионалов"). Например, здесь Вы можете найти основы проектирования БД:
http://www.sql.ru/forum/973198-65/db-specific-orm?hl=orm
Я Вам рекомендую, для начала, использовать М2. Это Вам поможет намного глубже понять проблему "ключей" - в частности, и проблему "реляционной технологии" - в целом.
...
Рейтинг: 0 / 0
24.05.2016, 00:25
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39242321
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Алексей SQL, не всем рекомендациям, следует доверять. А некоторые, просто достойны игнорирования (например, если кто-то подбросит Вам что-нибуь с названием похожим на М2). Чтобы понять рациональное в ключах лучше конечно читать Теорию реляционных Баз данных Д.Мейера. Иначе есть риски принять за основное, что-то производное. Например, что ключи придуманы для идентификации. Тогда как, на самом деле, для уникальности, а уникальность позволяет их использовать в каких-то случаях для идентификации.
...
Рейтинг: 0 / 0
24.05.2016, 14:46
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39242695
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
)))))
...
Рейтинг: 0 / 0
24.05.2016, 20:01
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39245522
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
Кот Матроскинsoftwarerпропущено...

Ну сходу: очевидно, что в payment_type поле name должно быть not null, а из каждой пары price_area и price_people должно быть заполнено какое-либо одно.

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

А что мешает создать услугу "охрана придомовой территории (чел.)" и услугу "охрана придомовой территории (площ.)" ?
...
Рейтинг: 0 / 0
28.05.2016, 23:50
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39245631
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Pulsar_pКот Матроскинпропущено...

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

А что мешает создать услугу "охрана придомовой территории (чел.)" и услугу "охрана придомовой территории (площ.)" ?
Ээ, здравый смысл?
Скажем, в квитке на оплату бухгалтер захочет видеть услугу одной строкой, и будет совершенно прав.
...
Рейтинг: 0 / 0
29.05.2016, 13:39
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39245804
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
Кот МатроскинPulsar_pпропущено...

А что мешает создать услугу "охрана придомовой территории (чел.)" и услугу "охрана придомовой территории (площ.)" ?
Ээ, здравый смысл?
Скажем, в квитке на оплату бухгалтер захочет видеть услугу одной строкой, и будет совершенно прав.
Так все как раз в здравом смысле и заключается. У меня, например, в зарплатном квитке бывает две строки "премия": суммой и коеффициентом, и я прекрасно понимаю, за что каждая.
Как квартплатному бухгалтеру, так и нанимателю(владельцу) квартиры удобней именно две строки, так проще сверить правильность расчета "врукопашную".
...
Рейтинг: 0 / 0
29.05.2016, 23:23
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246084
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Pulsar_pКот Матроскинпропущено...

Ээ, здравый смысл?
Скажем, в квитке на оплату бухгалтер захочет видеть услугу одной строкой, и будет совершенно прав.
Так все как раз в здравом смысле и заключается. У меня, например, в зарплатном квитке бывает две строки "премия": суммой и коеффициентом, и я прекрасно понимаю, за что каждая.
Как квартплатному бухгалтеру, так и нанимателю(владельцу) квартиры удобней именно две строки, так проще сверить правильность расчета "врукопашную".

Здравый смысл (tm) подсказывает, что когда нет ограничения "только одна цена может быть заполнена" - нет проблем ни с заведением двух разных услуг, если уж пользователю так хочется (хотя я считаю это плохим решением и постараюсь это им объяснить), ни с печатью одной услуги двумя строками - т.е. никакие возможности мы себе не закрыли.
А вот если ограничение есть , а услугу хотят видеть единой - вот тут количество проблем при поддержке начинает расти как снежный ком.
...
Рейтинг: 0 / 0
30.05.2016, 12:03
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246095
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
И тот же здравый смысл подсказывает, что поле "цена" должно быть текстовым. Чтобы не было проблем вписать туда "по договорённости".
...
Рейтинг: 0 / 0
30.05.2016, 12:14
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246104
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
softwarerИ тот же здравый смысл подсказывает, что поле "цена" должно быть текстовым. Чтобы не было проблем вписать туда "по договорённости".

Нет, это подсказывает не тот же здравый смысл ;)
...
Рейтинг: 0 / 0
30.05.2016, 12:21
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246160
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
Кот МатроскинsoftwarerИ тот же здравый смысл подсказывает, что поле "цена" должно быть текстовым. Чтобы не было проблем вписать туда "по договорённости".

Нет, это подсказывает не тот же здравый смысл ;)
Зря смеетесь. А если вышли противоречащие друг другу регламенты по тарифам? Это, конечно, не хорошо, но бухгалтеру в эту графу вбить все равно что-то надо.
...
Рейтинг: 0 / 0
30.05.2016, 13:28
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246172
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
Кот МатроскинPulsar_pпропущено...

Так все как раз в здравом смысле и заключается. У меня, например, в зарплатном квитке бывает две строки "премия": суммой и коеффициентом, и я прекрасно понимаю, за что каждая.
Как квартплатному бухгалтеру, так и нанимателю(владельцу) квартиры удобней именно две строки, так проще сверить правильность расчета "врукопашную".

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

Я приводил аргумент за две услуги, это простота сверки расчетов. Например, в сельской местности бухгалтеры очень дотошные, хотят контролировать программу лично лишь с помощью калькулятора. Квариросъемщики, в случае недопонимания, мчатся выяснять отношения (в резкой форме, разумеется) с сотрудниками расчетных центров. И не забывайте про льготы. Например, льгота положена лишь ветерану, а членам семьи - нет. Если одна строка в квитанции, далеко не каждый жилец сумеет ее правильно вычленить, если две - без проблем.
Кстати, в тарифообразовании стремятся уходить от расчетов с количества жильцов (в силу очевидных причин) в пользу квадратных метров.
...
Рейтинг: 0 / 0
30.05.2016, 13:43
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246200
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Pulsar_pКот Матроскинпропущено...


Нет, это подсказывает не тот же здравый смысл ;)
Зря смеетесь. А если вышли противоречащие друг другу регламенты по тарифам? Это, конечно, не хорошо, но бухгалтеру в эту графу вбить все равно что-то надо.

Я смеюсь не над тем, что "вышли противоречащие друг другу регламенты по тарифам", а над предлагаемым способом разруливания этого.

Pulsar_pЯ приводил аргумент за две услуги, это простота сверки расчетов.
"две услуги" и уровень детализация в квитке - это внезапно разные вещи.
Уровень детализации - это требование ТЗ (и возможно даже требования законодательства), никого не волнует тут мнение разработчика "как удобнее". И если мне с введенной в базу одной услугой придет требование "детализировать двумя строками" - я переделаю запрос на вывод услуги с заполненными двумя ценами 2 раза щелчком пальцев.
А если Вам с двумя услугами придет требование "выводить одной строкой" - Вам придется городить новые сущности/поля в БД, интерфейсы для их редактирования, etc. etc.
А если потребуется еще и платеж по этим двум услугам генерировать один - страшно себе представить что будет.
...
Рейтинг: 0 / 0
30.05.2016, 14:14
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246259
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
Кот Матроскин,
Да, пожалуй. Но все-таки по дефолту я бы запретил заполнять эти два поля одновременно, потому как появление такой двухуровневой услуги маловероятно. И дал бы возможность снять это ограничение лишь пользователю с админскими правами где-нибудь в настройках программы.
...
Рейтинг: 0 / 0
30.05.2016, 15:06
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246261
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
SERG1257Но вообще сама постановка - только один платеж в месяце выглядит бредово по-жизни.
>Мы не можем принять вашу оплату, так как вы уже платили в этом месяце

Такое ограничение действительно существовало одно время, не знаю как сейчас. И причина достаточно объективна.

Суть в том, что если абонент заплатил коммунальщикам за уже оказанную услугу, например, за тепло, то его деньги идут на оплату топлива, зарплаты, других накладных расходов предприятия, и лишь какая-то часть остается как прибыль. Она, грубо говоря, облагается налогом на прибыль (на самом деле всякими разными, но суть в том, что довольно большими), и с остатка уже можно платить себе премии и делать что угодно.

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

Поэтому прием авансовых платежей тупо запрещался. Есть счет - оплати и гуляй, жди следующего. Думаю, именно это имелось в виду.
...
Рейтинг: 0 / 0
30.05.2016, 15:09
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246311
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
Pulsar_pНо все-таки по дефолту я бы запретил заполнять эти два поля одновременно, потому как появление такой двухуровневой услуги маловероятно.

Есть такие услуги. Например, есть такая штука - двухконтурный газовый котел. Внешне обычный белый ящик, но умеет и комнату отопить, и для душа воду нагреть.

Так вот, нормативное потребление им газа в месяц считается именно как отапливаемая площадь * всякие цены и коэффициенты + количество проживающих * всякие другие цены и коэффициенты.

Другое дело, что сейчас все платят не по нормативке, а по счетчикам (кстати, у ТС про это ни слуху ни духу), но нормативный расчет все равно используется как база для всяких социальных плюшек, а также штрафов в случае умышленной порчи счетчика и незаконного подключения.
...
Рейтинг: 0 / 0
30.05.2016, 15:49
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246326
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
Cane Cat Fisher...
А если абонент с какой-то радости заплатил второй раз в месяц, то есть наперед, то весь его платеж идет как прибыль...
...

С чего вдруг? Самая обыкновенная предоплата.
У нас другой прикол был. Накануне объявленного крупного повышения тарифов, коллега по работе в графе показаний счетчиков поставила безумно высокую цифру. Ну, то есть, решила заплатить за будущий период по старым тарифам. Ага, не на тех нарвалась. Там такие пройдохи, ни на какой кобыле не объедешь. Счетчик заставили поменять, типа неисправный.
...
Рейтинг: 0 / 0
30.05.2016, 15:59
| Ответить | Цитировать | Написать  
Запутался с ключами
    #39246345
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
Pulsar_pС чего вдруг? Самая обыкновенная предоплата.

Там по каким-то налоговым пирогам получалось, что предоплаты быть не может. Короче, у налоговой свой взгляд на мир: Месяц закончился? Деньги остались? Снимай штаны Плати налог.
...
Рейтинг: 0 / 0
30.05.2016, 16:28
| Ответить | Цитировать | Написать  
39 сообщений из 39, показаны все 2 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Запутался с ключами
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1540333]:
 0ms
get settings:
 7ms
get forum list:
 11ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 151ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 63ms
get tp. blocked users:
 1ms
others: 11ms
total:  265ms
созд. / загр.: 265ms
x
x
Закрыть


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