ER модель — это модель. А БД — это БД. ERмоделью можно моного что моделировать. НАпример, ООП

Так почему же тогда нет разницы?)

Запрос напиши, и получишь связь

Какой еще запрос? Я про шлюз к записи говорил. В классе, описывающем страну просто не может быть никакого упоминания про город в рассматриваемом случае.

Какой еще запрос? Я про шлюз к записи говорил. В классе, описывающем страну просто не может быть никакого упоминания про город в рассматриваемом случае.

Как говорица, видишь суслика? А он есть.

Дайте определение связи наконец))

Какой еще запрос? Я про шлюз к записи говорил. В классе, описывающем страну просто не может быть никакого упоминания про город в рассматриваемом случае.

В стране нет города, а связь страны с городам — есть.

Дайте определение связи наконец))

В РБД НЕТ связей. Поэтому давать определение связи бессмысленно

Связи есть только в даталогической модели.

Какой еще запрос? Я про шлюз к записи говорил. В классе, описывающем страну просто не может быть никакого упоминания про город в рассматриваемом случае.

Потом, Виталий, какие ещё КЛАССЫ ?

Т.е. мы пришли к тому что формулировка "таблица имеет связь" бессмысленна?

Потому что таблица - часть РБД

В теоретическом смысле да

Чтд

Потом, Виталий, какие ещё КЛАССЫ ?

Про ООП можно, а про классы нет? Так не по джентльменски.

В практическом же мы же все БД-специалисты, да? Мы понимаем, что связей в РБД нет, поэтому мы используем этот термин для обозначения ДРУГОГО.

А именно, связи в хранящихся в РБД данных.

(которые, св/язи, из даталогической модели)

Т.е. речь идёт чисто о сленге, ок

Но требовалось точная формулировка

че вас с утра на философию то потянуло

Тогда они у нас уже ЕСТЬ, и они все ДВУНАПРАЛЕННЫЕ, или в более общем случае , связывающие 2 и более сущности.

Процитирую кусок определения. > Сущность СТУДЕНТЫ имеет с сущностью Успеваемость связь «один – ко - многим», так как понятие «успеваемость студента» представляет совокупность его оценок по нескольким предметам. Если реализовать эту связь то внешний ключ будет в таблице Успеваемость на студента так? Почему они пишут что студенты имеют связь если прямой ссылки на успеваемость нету?

Требовалось ответить вот на этот вопрос.

Требовалось ответить вот на этот вопрос.

И ответ — неправильно сформулировано условие. Успеваемость — это уже связь многие-ко-многим

И ответ — неправильно сформулировано условие. Успеваемость — это уже связь многие-ко-многим

Давайте оставим этот пример. Изначально вопрос был про Страна-Город

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

Тут проще, Страна - один-ко-многим— Город

Правда, нужно сначала выяснить, не может ли быть так, что один город может находится в нескольких странах.

Или город без страны.

Правда, нужно сначала выяснить, не может ли быть так, что один город может находится в нескольких странах.

? ?

Ну или уточнить, что значит эта связь, какой смысл мы в нёё вкладываем, географическое помещение в страну, административное подчинение или что-то ещё.

Давай усложню)) товары, покупатели, чеки. Описывать не буду, понятно. Вопрос - товары имеют связь с покупателем?

После покупки — да

чек — это их связь

А таблицы то нет))

Почему нет ?

Вопрос про таблицы был

После покупки — да

В базу они попадают до покупки

Там две даже таблицы должны быть, чек и позиции чека

ПОсле покупки в базу должен попасть чек и его состав

(в смысле экземпляр чека)

Потому что нет. Это не вопрос достижимости, иначе с покупателем будет связан классификатор типов товара например

А сами-то таблицы и до покупки существуют

Если взять покупателя, все его покупки, товары из его покупок, и связать товары с классификатором товаров, то получим классификацию купленных покупателем товаров.

Получается, что покупатель связан с классификатором покупаемых товаров, а почему нет-то?

В этом и сила РСУБД, что СВЯЗЕЙ НЕТ, они все строятся на лету...

Иными словами по-твоему связь - это все что можно впихнуть в скл-запрос с условиями выборки по ключам?))

Именно

Что-то мне подсказывает, что имелось в виду нечто иное)

А по-твоему что есть свя/зь?

ИМЕЛОСЬ в виду именно это

Всем привет! Сразу по существу: есть mysql. Есть таблица с полем типа date. На поле стоит index. При выборе данных mysql отказывается думать об индексе. Или может я в чем-то не прав, подскажите, пожалуйста. Вот sql запрос: explain SELECT report_id,qt FROM report_data WHERE report_id IN (SELECT reports.id FROM reports WHERE report_date BETWEEN '2016-12-01' AND '2016-12-01') В поле типа type стоит занчение all и не используются ключи.

ИМЕЛОСЬ в виду именно это

Я повторюсь, что имелась в виду ерунда как по мне, мешанина понятий. Отсюда и вся дискуссия. Потому что к объектам рбд применяется понятие не отсюда

Ну это не проблема. Сколько записей в таблице? И сколько с report_date BETWEEN '2016-12-01' AND '2016-12-01' ?

А по-твоему что есть свя/зь?

Для меня связь - понятие из ЕR

Для меня связь - понятие из ЕR

Ну да. И для меня тоже

Ну это не проблема. Сколько записей в таблице? И сколько с report_date BETWEEN '2016-12-01' AND '2016-12-01' ?

В таблице report_data немного - мил 100 наверно between возвращает до 100 к записей

Для меня связь - понятие из ЕR

У тебя в запросах именно эта связь и фигурирует. Именно она в запросах восстанавливается

Поэтому оно чуть более большой охват даст в наложеннии на рбд, за счёт многие ко многим и отсутствия необходимсти внешних ключей как индикатора, но не расползется по всему дереву достижимости

В таблице report_data немного - мил 100 наверно between возвращает до 100 к записей

100 млн записей — это много. Если 100к возвращаться примернодолжно, то индекс тут невыгоден, использоваться не будет

100 млн записей — это много. Если 100к возвращаться примернодолжно, то индекс тут невыгоден, использоваться не будет

Ага, то есть mysql мне пытается намекнуть что он и без индекса могет быстро?

Ага, то есть mysql мне пытается намекнуть что он и без индекса могет быстро?

Нет, пытается намекнуть, что без индекса будет быстрее, чем с индексом

Нет, пытается намекнуть, что без индекса будет быстрее, чем с индексом

да, да. именно так я и уловил. Хорошо, пока не буду его трогать.. Хотя если из запроса убрать qt, то он почему-то индекс берет

Нет, пытается намекнуть, что без индекса будет быстрее, чем с индексом

explain SELECT report_id FROM report_data WHERE report_id IN (SELECT reports.id FROM reports WHERE report_date BETWEEN '2016-12-01' AND '2016-12-01') вот так будет тип index

да, да. именно так я и уловил. Хорошо, пока не буду его трогать.. Хотя если из запроса убрать qt, то он почему-то индекс берет

потому что это разные запросы,

потому что это разные запросы,

Понятно. А вот если глобально говорить. subquery много хуже чем left join? То есть когда данные раскиданы по таблицам и при большом запросе выдергиваются некоторые поля по условию.

Т.е. у тебя вот этот вот (SELECT reports.id FROM reports WHERE report_date BETWEEN '2016-12-01' AND '2016-12-01') список будет из сотни тыщ записей, а затем ты по ним ещё какуюто детальную информацию выбрать хочешь? И сколько же там будет записей? И нафига ж тебе столько то?

Понятно. А вот если глобально говорить. subquery много хуже чем left join? То есть когда данные раскиданы по таблицам и при большом запросе выдергиваются некоторые поля по условию.

Многое зависит от оптимизатора, он некоторые запросы с коррелированными подзапросами может и преобразовать в Join, если это возможно.

Т.е. у тебя вот этот вот (SELECT reports.id FROM reports WHERE report_date BETWEEN '2016-12-01' AND '2016-12-01') список будет из сотни тыщ записей, а затем ты по ним ещё какуюто детальную информацию выбрать хочешь? И сколько же там будет записей? И нафига ж тебе столько то?

У меня это просто условие ) То есть есть таблица в которой собраны id всякие. В том числе и report_id Я выбираю из этой таблицы большу кучу, и бегу в другие таблицы, где по id забираю что-то типа name или title

Понятно. А вот если глобально говорить. subquery много хуже чем left join? То есть когда данные раскиданы по таблицам и при большом запросе выдергиваются некоторые поля по условию.

Твой вопрос из цикла "Чем ворон лучше, чем писменный стол". несоотносимые понятия

Твой вопрос из цикла "Чем ворон лучше, чем писменный стол". несоотносимые понятия

Понимаю, что все зависит от контекста

от конкретной задачи

Многое зависит от оптимизатора, он некоторые запросы с коррелированными подзапросами может и преобразовать в Join, если это возможно.

В том же Mysql оптимизатор весьма посредственный в вопросах подзапросов

Понимаю, что все зависит от контекста

Твой запрос можно переписать на JION. Ничего не изменится. Другие с подзапросами, может и нельзя. подзапросы и JOIN-ы реализуют разные реляционные операции , их бессмысленно сравнивать

Твой запрос можно переписать на JION. Ничего не изменится. Другие с подзапросами, может и нельзя. подзапросы и JOIN-ы реализуют разные реляционные операции , их бессмысленно сравнивать

Я так понимаю, чтобы понять, что будет быстрее, нужно только пробовать?

Нет, не обязательно

МОжно поглядеть планы

Можно просто прикинуть умом пораскинуть.

Но для этого нужно понимание того, как запросы выполняются.

(только для последнего)

Но для этого нужно понимание того, как запросы выполняются.

Вот тут есть некий пробел.. в планах)

Твой запрос напр. сразу видно, что "плохой", безнадёжный. (если конечно там за день 100тыщ)

Твой запрос напр. сразу видно, что "плохой", безнадёжный. (если конечно там за день 100тыщ)

Не у меня есть таблица которая пополняется раз примерно в месяц на 1 млн записей

не сразу в течении

а потом я такой хоба, и хочу получить из нее определеные данные

конечно при помощи всяких условий

чтобы не брать все данные

Твой запрос напр. сразу видно, что "плохой", безнадёжный. (если конечно там за день 100тыщ)

Чтобы немного приотркыть завесу: table1 id, user_id,page_id,state_id,qt table2 id,user_name table3 id, page_title table4 id,state_title И вот я иду в table1 и хочу получить данные, но не id и норм названия. Условия могут быть и в подзапросах: нужен user_name только если у него поле good = 1

ER модель — это модель. А БД — это БД. ERмоделью можно моного что моделировать. НАпример, ООП

oh my

Нормализация БД относится к логическому проектированию модели БД?

Вобщем 23к записей из БД выгружаются за 112 секунд... наверно это многовато

Нормализация БД относится к логическому проектированию модели БД?

Сожно сказать

А что значит "нормализация БД"?

Вроде нормализуют данные...

А что значит "нормализация БД"?

Выявление функциональных зависимостей в данных и проектирование БД в соответствии с нормальными формами РБД.

Это же нормализация данных