Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[34.229.50.161] |
|
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных - обсуждаем в разделе "Базы данных: общие вопросы". Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Решаемая задача приводит к формированию нереляционного набора данных. В книгах по SQL такой хренью никто не занимается, обоснованно считая, что этим должна заниматься интерфейсная часть. И введение в некоторые диалекты PIVOT в этом смысле ничего не меняет. |
Сообщ.
#17
,
|
|
|
Цитата Akina @ Решаемая задача приводит к формированию нереляционного набора данных. Кстати о птичках. В MySQL/PostgeSQL есть тип JSON (в постгрессе еще и Array), чем собственно можно воспользоваться по вопросу выше. Будет ли такой набор реляционным? |
Сообщ.
#18
,
|
|
|
Цитата JoeUser @ Будет ли такой набор реляционным? Может будет, может, нет. Смотря что за набор. Но вот нормализованным он не будет стопудово. |
Сообщ.
#19
,
|
|
|
Цитата Akina @ Но вот нормализованным он не будет стопудово. Это с чевойто? Нормализация, сиречь - есть обеспечение неизбыточности данных. В "пожеланиях" ТС избыточности нет ваще напроч - (один день_один ученик_его оценки), единичное упоминание без какого-то рода отношений. Имхо, тут все ровно. На счет реляционности. По заявлениям из вики - малеха туманно. Но, тем не менее ... 1) Структурная составляющая - действительно получаются обозначимые отношения (в разрезе записей) 2) Составляющая целостности - действительно отношения получаются однозначными (дублирования нет) 3) Составляющая обработки - действительно есть возможность выделения нужного путем запросов (любое поле можно выбрать запросом) Получается и с реляционностью все не так плохо |
Сообщ.
#20
,
|
|
|
Цитата JoeUser @ Нормализация, сиречь - есть обеспечение неизбыточности данных. Ась? Нормализация - это приведение к нормальной форме. При чём тут избыточность данных - я фиг знает, хотя как правило отсутствие избыточности есть одно из следствий нормализации. А данный запрос формирует несколько независимых атрибутов записи (оценка за определённый день), содержащих экземпляры одного атрибута (оценка) сущности ученик. Что ни одной из нормальных форм не соответствует. Денормализация налицо. Цитата JoeUser @ 2) Составляющая целостности - действительно отношения получаются однозначными (дублирования нет) Ошибочное утверждение. В данном случае однозначность отношений обеспечивается внешним механизмом контроля исходных данных. Да и сам ТС соглашается, что в один день может быть несколько оценок. Более того, он начинает соглашаться, что исходные данные могут влиять на структуру результата - какая уж тут на фиг реляционность? |
Сообщ.
#21
,
|
|
|
Цитата Akina @ Ась? Нормализация - это приведение к нормальной форме. При чём тут избыточность данных - я фиг знает Цитата Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Цитата Akina @ одно из следствий нормализации Наоборот все Уменьшение избыточности - это цель, это главное. А нормализация - это способ, это второстепенное, читай следствие. Добавлено Цитата Akina @ В данном случае однозначность отношений обеспечивается внешним механизмом контроля исходных данных. Тип "массив" или JSON ничем не отличается от той же "строки". Это единый элемент - это главное. Для "строки" есть функция получения подстроки, для "массива" есть функция получения i-го подэлемента. Никаких внешних механизмов не наблюдаю - все реализуется возможностями движка БД. |