M
линейно, да
Нужен план
Хмм... а разве это вообще дальнейшая нормализация?
Где в (x, y, price, PK (x, y)) какие-то проблемы / аномалии / нарушения принципов нормализации?
Size: a a a
2021 January 25
RK
Yaroslav Schekin
Не могли бы вы переформулировать вопрос? С учётом того что я чуть больше чем полностью не разбираюсь в нормализации данных в БД и с PG работаю методом тыка. Просто не хватает знаний понят то о чем вы спрашиваете.
YS
Не могли бы вы переформулировать вопрос? С учётом того что я чуть больше чем полностью не разбираюсь в нормализации данных в БД и с PG работаю методом тыка. Просто не хватает знаний понят то о чем вы спрашиваете.
Это же я Вас спрашиваю! ;)
Почему Вы вообще считаете то, что предлагаете, нормализацией, Вы можете объяснить?
Почему Вы вообще считаете то, что предлагаете, нормализацией, Вы можете объяснить?
T
Не могли бы вы переформулировать вопрос? С учётом того что я чуть больше чем полностью не разбираюсь в нормализации данных в БД и с PG работаю методом тыка. Просто не хватает знаний понят то о чем вы спрашиваете.
T
Часть 2.
RK
Yaroslav Schekin
Это же я Вас спрашиваю! ;)
Почему Вы вообще считаете то, что предлагаете, нормализацией, Вы можете объяснить?
Почему Вы вообще считаете то, что предлагаете, нормализацией, Вы можете объяснить?
Ну, конечно, же я мог использовать неверные термины. Для меня табличка всё в одном это ненормализованная табличка. А куча табличек с уникальными данными в них, при этом связанные друг с другом - это уже нормализованно. Моя задача избавиться от "копий" данных в бд и иметь возможность делать выборки по критерию, который я описал выше.
YS
Ну, конечно, же я мог использовать неверные термины. Для меня табличка всё в одном это ненормализованная табличка. А куча табличек с уникальными данными в них, при этом связанные друг с другом - это уже нормализованно. Моя задача избавиться от "копий" данных в бд и иметь возможность делать выборки по критерию, который я описал выше.
И я так и не понял, где в начальной модели (я правильно её описал выше?) хоть одна из этих проблем (неуникальные данные, или копии — что угодно)?
RK
Не. Оперировать хочется простыми терминами. Сложно я не понимаю. Табличками и связями. Вопрос был в том, хранить ли табличку "ММВБ, ДОЛЛАР\РУБ, ЦЕНА" или Хранить табличку "биржи", табличку "валюта", табличку "цена" и + связующие таблицы, которые потом и вязать через JOIN для запросов данных.
D
второе (в общем случае)
YS
Не. Оперировать хочется простыми терминами. Сложно я не понимаю. Табличками и связями. Вопрос был в том, хранить ли табличку "ММВБ, ДОЛЛАР\РУБ, ЦЕНА" или Хранить табличку "биржи", табличку "валюта", табличку "цена" и + связующие таблицы, которые потом и вязать через JOIN для запросов данных.
А связующая таблица-то у Вас как будет выглядеть?
Как "ММВБ, ДОЛЛАР\РУБ, ЦЕНА", да? ;)
Конечно, таблицы "биржи" и т.п. должны быть, но что в структуре "связующих" меняется?
Как "ММВБ, ДОЛЛАР\РУБ, ЦЕНА", да? ;)
Конечно, таблицы "биржи" и т.п. должны быть, но что в структуре "связующих" меняется?
RK
Yaroslav Schekin
А связующая таблица-то у Вас как будет выглядеть?
Как "ММВБ, ДОЛЛАР\РУБ, ЦЕНА", да? ;)
Конечно, таблицы "биржи" и т.п. должны быть, но что в структуре "связующих" меняется?
Как "ММВБ, ДОЛЛАР\РУБ, ЦЕНА", да? ;)
Конечно, таблицы "биржи" и т.п. должны быть, но что в структуре "связующих" меняется?
Ну даже не знаю как объяснить. Ну вот смотрите. Есть таблица биржа. В ней строка id=1, "MMVB". Есть таблица валюта id=1, "USD". Вяжу их таблицей exch_to_tick со столбиками exch_id=1, tick_id=1, 20-20-2020:15:15:15. Вроде того. И в связующей как я понимаю столбцы это pk
YS
Ну даже не знаю как объяснить. Ну вот смотрите. Есть таблица биржа. В ней строка id=1, "MMVB". Есть таблица валюта id=1, "USD". Вяжу их таблицей exch_to_tick со столбиками exch_id=1, tick_id=1, 20-20-2020:15:15:15. Вроде того. И в связующей как я понимаю столбцы это pk
Да, допустим.
Только вот наличие суррогатных id не повышает уровня нормализации (а вот понизить может, при неосторожном использовании). Т.е. обычно они к нормализации не имеют отношения, являясь понятием из "физического" проектирования.
Т.е. "биржа(название UNIQUE)" и "биржа(id PRIMARY KEY, название UNIQUE)" — по сути одно и то же.
То же касается и таблиц many-to-many, т.е. "(id_биржи, id_валюты, ...)" и "(название_биржи, название_валюты, ...)" — по сути одно и то же. Вторую модель используют, надеясь достигнуть большей производительности, а никакого отношения к нормализации это всё не имеет.
Только вот наличие суррогатных id не повышает уровня нормализации (а вот понизить может, при неосторожном использовании). Т.е. обычно они к нормализации не имеют отношения, являясь понятием из "физического" проектирования.
Т.е. "биржа(название UNIQUE)" и "биржа(id PRIMARY KEY, название UNIQUE)" — по сути одно и то же.
То же касается и таблиц many-to-many, т.е. "(id_биржи, id_валюты, ...)" и "(название_биржи, название_валюты, ...)" — по сути одно и то же. Вторую модель используют, надеясь достигнуть большей производительности, а никакого отношения к нормализации это всё не имеет.
RK
Yaroslav Schekin
Да, допустим.
Только вот наличие суррогатных id не повышает уровня нормализации (а вот понизить может, при неосторожном использовании). Т.е. обычно они к нормализации не имеют отношения, являясь понятием из "физического" проектирования.
Т.е. "биржа(название UNIQUE)" и "биржа(id PRIMARY KEY, название UNIQUE)" — по сути одно и то же.
То же касается и таблиц many-to-many, т.е. "(id_биржи, id_валюты, ...)" и "(название_биржи, название_валюты, ...)" — по сути одно и то же. Вторую модель используют, надеясь достигнуть большей производительности, а никакого отношения к нормализации это всё не имеет.
Только вот наличие суррогатных id не повышает уровня нормализации (а вот понизить может, при неосторожном использовании). Т.е. обычно они к нормализации не имеют отношения, являясь понятием из "физического" проектирования.
Т.е. "биржа(название UNIQUE)" и "биржа(id PRIMARY KEY, название UNIQUE)" — по сути одно и то же.
То же касается и таблиц many-to-many, т.е. "(id_биржи, id_валюты, ...)" и "(название_биржи, название_валюты, ...)" — по сути одно и то же. Вторую модель используют, надеясь достигнуть большей производительности, а никакого отношения к нормализации это всё не имеет.
Ага, я вас понял. Ну я упомянул уже, что, возможно, я неверное оперирую терминами или не те и не там применяю. Суть ясна.
K
если использовать
но надо осторожно, можно больно сделать…
psql, то можно сформировать запросы через SQL и завершить его \gexec — тогда psql вывод запроса отдаст базе ещё раз.но надо осторожно, можно больно сделать…
все таки пришлось писать функцию. Спасибо
w
Добрый день! Такая проблема, создал пользователя только на чтение, к базам подключается в пгадмин, а скрипты выполнить не может. Скажите в какую сторону копать, или посмотреть права
РЖ
Добрый день! Такая проблема, создал пользователя только на чтение, к базам подключается в пгадмин, а скрипты выполнить не может. Скажите в какую сторону копать, или посмотреть права
Там, в пгадмин, должен быть секретный текст ошибки.
w
Permission denied for table “название” sql state:42501