Запрос не совпадает с выводом на скрине

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

Вы определитесь, какую проблему решаем и такой запрос и давайте...

а то запрос один, а проблему решаем в другом запросе...

Проблема именно в приведенном запросе, тот скрин я для пояснения приложил, но внёс смуту, прошу прощения.

в запросе, который вы написали, проблем с дублированием нет

В выводе - нет. Он именно суммирует дубликаты. На первом скрине видно, что для клиента повторяются услуги два раза и два раза одни и те же материалы. Т.е реальная стоимость будет в два рааз меньше, чем та, которую я получаю из запроса.

если структура не кривая, то мне кажется касяк в джойнах

все таки покажите запрос под этот скрин

SELECT dbo.Клиенты.ФИО_клиента, dbo.Услуги.Название_услуги, dbo.КлиентыУслуги.Количество_услуг, dbo.Материалы1.Название_материала, dbo.КлиентыМатериалы.Количество_материала FROM dbo.Клиенты INNER JOIN dbo.КлиентыМатериалы ON dbo.Клиенты.Код_клиента = dbo.КлиентыМатериалы.Код_Клиента INNER JOIN dbo.КлиентыУслуги ON dbo.Клиенты.Код_клиента = dbo.КлиентыУслуги.Код_Клиента INNER JOIN dbo.Материалы1 ON dbo.КлиентыМатериалы.Код_Материала = dbo.Материалы1.Код_материала INNER JOIN dbo.Услуги ON dbo.КлиентыУслуги.Код_Услуги = dbo.Услуги.Код_услуги

хм, оригинальная структура...

разбивайте услуги и материалы

Отдельно просуммировать имеете в виду? или как?

Хотя, это может быть выход.

отдельно находите сумму по материалам для клиента и отдельно сумму по услугам

а потом суммируете

Да-да, кажется, я понял. Сейчас уже домучаюсь с частью клиентского приложения и опробую, спасибо.

у вас материалы и услуги не согласованы, поэтому происходит связь M:M

SELECT dbo.Клиенты.ФИО_клиента, dbo.Услуги.Название_услуги, dbo.КлиентыУслуги.Количество_услуг, dbo.Материалы1.Название_материала, dbo.КлиентыМатериалы.Количество_материала FROM dbo.Клиенты INNER JOIN dbo.КлиентыМатериалы ON dbo.Клиенты.Код_клиента = dbo.КлиентыМатериалы.Код_Клиента INNER JOIN dbo.Материалы1 ON dbo.КлиентыМатериалы.Код_Материала = dbo.Материалы1.Код_материала INNER JOIN UNION ALL SELECT dbo.Клиенты.ФИО_клиента, dbo.Услуги.Название_услуги, dbo.КлиентыУслуги.Количество_услуг, dbo.Материалы1.Название_материала, dbo.КлиентыМатериалы.Количество_материала FROM dbo.Клиенты INNER JOIN dbo.КлиентыУслуги ON dbo.Клиенты.Код_клиента = dbo.КлиентыУслуги.Код_Клиента INNER JOIN dbo.Услуги ON dbo.КлиентыУслуги.Код_Услуги = dbo.Услуги.Код_услуги

Вот например

логически, у вас что услуга, что материал - это равноценные позиции, а вы пытаетесь использовать их как одно подмножество другово

Вообще, изначально, я хотел все сделать по-другому, но меня буквально заставили делать так. Теперь вот и приходится страдать немного :) Спасибо за помощь, скоро вернусь к этому, надеюсь все получится.

SELECT Клиенты.ФИО_клиента, SUM(xz.Cтоимость) AS Cтоимость FROM Клиенты INNER JOIN ( SELECT КлиентыУслуги.Код_Клиента, SUM(Услуги.Стоимость_услуги_руб*КлиентыУслуги.Количество_услуг) AS Cтоимость FROM КлиентыУслуги INNER JOIN Услуги ON КлиентыУслуги.Код_Услуги = Услуги.Код_услуги GROUP BY Клиенты.Код_клиента UNION ALL SELECT КлиентыМатериалы.Код_Клиента, SUM(КлиентыМатериалы.Количество_материала*Материалы1.Цена_за_единицу) AS Cтоимость FROM КлиентыМатериалы INNER JOIN Материалы1 ON КлиентыМатериалы.Код_Материала = Материалы1.Код_материала INNER JOIN GROUP BY КлиентыМатериалы.Код_Клиента ) AS xz ON Клиенты.Код_клиента = xz.Код_Клиента

Вот так

Запрос не блещет скоростью, нужна будет оптимизация, то тогда убирайте группировки из подзапроса и выносите в основной запрос

логически, у вас что услуга, что материал - это равноценные позиции, а вы пытаетесь использовать их как одно подмножество другово

ну можно is_service какйонеть внести еще

но вообще надо делить да

сущности разные

ну можно is_service какйонеть внести еще

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

да я не настаиваю что это лучшее решение

но так как есть еще хуже

Запрос не блещет скоростью, нужна будет оптимизация, то тогда убирайте группировки из подзапроса и выносите в основной запрос

Скорость мне не важна, это для зачета, им пойдет и неоптимизированное. А чисто для себя уже сил не хватит. Ибо почти 4 часа утра.

всем привет!

гуру ДБА, подскажите, а как можно удалить все строки оставив лишь последние N штук?

делит фром тэйбл ордер бай ид деск лимит эн?

create table as select + drop + rename

а, нет. в гугле советуют подзапросы

create table as select + drop + rename

попробую

а, нет. в гугле советуют подзапросы

погуглю

гуру ДБА, подскажите, а как можно удалить все строки оставив лишь последние N штук?

понятие последних строк очень спорно...

понятие последних строк очень спорно...

почему?

потому что нет определения, что считать последними строками

последние вставленные, последние измененые, последние по значению даты в одном из столбцов?

в моем случае самый последний - это самый большой id (auto_increment)

так и думал, что так ответите, надеюсь у вас нет вставки данных с этим самым id, в противном случае вас ждут удивительные результаты

уточню, спасибо

в базе данных нет понятия порядка строк

пока ордер бая нет, она имеет право возвращать любой порядок

в базе данных нет понятия порядка строк

зависит от базы, но по определению да, рандом

пока ордер бая нет, она имеет право возвращать любой порядок

А я думал по сортировке первичного ключа по умолчанию. Не?

Если имеется такой

вообще нет

чаще всего по вставке

А я думал по сортировке первичного ключа по умолчанию. Не?

ребят, вам бы спеки почитать

A cursor in the open state identifies a table, an ordering of the rows of that table, and a position relative to that ordering. If the <declare cursor> does not include an <order by clause>, or includes an <order by clause> that does not specify the order of the rows completely, then the rows of the table have an order that is defined only to the extent that the <order by clause> specifies an order and is otherwise implementation-dependent.

"думал" и "предполагал" - это вообще плохие слова в этой отрасли

говоря проще, в каком порядке проще было вернуть, в таком и вернет. можно много говорить о том, какой порядок более дешев при работе с B+-trees и MVCC etc., но факт в том, что он для пользователя случаен и может меняться между транзакциями

например, одна СУБД при наличии limit сперва вернет те листья дерева, которые случайно есть в памяти

и будет абсолютно права

Может кто-нибудь подсказать по mysql (5.7)? Какой-нибудь параметр или механизм защиты от подбора пароля. Безопасники брутфорсят пароль, при этом СУБД начинает тупить.

fail2ban mysql + google

угу, попробуй выполнить этот запрос

там найдешь кучу заметок о том, что это нерабочая связка

Может кто-нибудь подсказать по mysql (5.7)? Какой-нибудь параметр или механизм защиты от подбора пароля. Безопасники брутфорсят пароль, при этом СУБД начинает тупить.

Вайтлист на порт?

ERROR: S client not available

я так понял, что безопасники - это внутренний отдел, которые по умолчанию во всех белых списках

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

я так понял, что безопасники - это внутренний отдел, которые по умолчанию во всех белых списках

О_о Вы чё с дубу рухнули?

Подлючения к базе должны идти в порядке запрет всем, открыть только списку: список должен включать себя только те конкретный ИП (не подсети), конкретных серверов, которым вы хотите разрешить доступ к ДБ

Четам?

Я проскролил... похоже на его же книгу по перформансам, но в ужатом формате для детей )

Но по крайне мере легче понимать некоторые вещи по рисункам

Но по крайне мере легче понимать некоторые вещи по рисункам

Книжка-малышка Секс в картинках?

Я знаю про fail2ban и просто про iptables. Но они безопасник должны иметь возможность подбирать пароль, но хотелось бы, чтоб СУБД при этом не падал.

Я знаю про fail2ban и просто про iptables. Но они безопасник должны иметь возможность подбирать пароль, но хотелось бы, чтоб СУБД при этом не падал.

Зачем безопасникам подбирать пароль?

Я знаю про fail2ban и просто про iptables. Но они безопасник должны иметь возможность подбирать пароль, но хотелось бы, чтоб СУБД при этом не падал.

Чудны дела твои, господи

Зачем безопасникам подбирать пароль?

Зп за что получать?

Так они на вопрос "что делаете", всегда могут ответить - "пароли подбираем"

Можно еще ебать человека, чей пароль они подобрали

А ваще можно настроить репликацию паролей и пусть они на другом инстансе подбирают

А ваще можно настроить репликацию паролей и пусть они на другом инстансе подбирают

Зачем?

Какой-то бред

Чтобы безопасности могли брутить пароли

должны ли безопасники заниматся соц.инженирингом

ну типа проверять сотрудников компании

просить выгрузить какую нибудь инфу

или расказать что то

Подлючения к базе должны идти в порядке запрет всем, открыть только списку: список должен включать себя только те конкретный ИП (не подсети), конкретных серверов, которым вы хотите разрешить доступ к ДБ

Не всегда. Часто нужно всем давать доступ, ну я тут жопу прикрываю fail2ban + пользователи mysql по IP

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

Маразм

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

зачем и рута давать. пусть сами подбирают

им*

зачем и рута давать. пусть сами подбирают

А зачем доступ к базе для подбирания пароля

Я знаю про fail2ban и просто про iptables. Но они безопасник должны иметь возможность подбирать пароль, но хотелось бы, чтоб СУБД при этом не падал.

Позиция не логичная... Объясняется легко, если безопасники считают, что пароль может быть уязвим, то пускай тогда тестируют весь фронт работ, начиная от обхода блокировок и прочего...

Позиция не логичная... Объясняется легко, если безопасники считают, что пароль может быть уязвим, то пускай тогда тестируют весь фронт работ, начиная от обхода блокировок и прочего...

Угу и для брутфорса используют стандартный интерфейс