select, sum как правильней

← →
dest81 (2011-07-06 16:19) [0]

Усть две таблицы:

1. dogovor
id
name

2. plata
id
id_dg
suma

Как правильнее вывести sum(suma) по каждому договору, и надо что б выводились и те договора по которых непроисходили проплаты (если можно то с нульом).

← →
Медвежонок Пятачок © (2011-07-06 16:24) [1]

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

← →
Anatoly Podgoretsky © (2011-07-06 16:32) [2]

В форум по ИБ

← →
dest81 (2011-07-06 16:40) [3]

Пасибо ребята! Хорошо что подсказали ...

Ключевое слово "правильнее"
Я делаю так
select t1.id,
sum(t2.suma)
from dogovor t1
left join plata t2 on t1.id=t2.id
group by t1.id

просто при 10000-ах записей делается очень долго, хотя такой запрос:
select id,sum(suma) from plata group by id
очень быстро

← →
Медвежонок Пятачок © (2011-07-06 16:46) [4]

как правильнее вывести?

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

← →
Медвежонок Пятачок © (2011-07-06 16:51) [5]

ну а в наше время суммы правильнее всего выводить в оффшор

← →
Inovet © (2011-07-06 16:56) [6]

> [3] dest81 (06.07.11 16:40)
> делается очень долго

Индексы есть?

← →
dest81 (2011-07-06 17:00) [7]

> Inovet ©

Если често то нет! віставить по обеим полям? Просто сума у меня не есть поисковым полем.

← →
tesseract © (2011-07-06 17:10) [8]

> Если често то нет! віставить по обеим полям?

Ключи хоть на id поставь и то хорошо будет.

← →
картман_ (2011-07-06 17:15) [9]

и по-русски, по-русски балакать начинай

← →
Inovet © (2011-07-06 17:18) [10]

На dogovor id в определении таблицы primary key
На plata id_dg лучше сразу указать в определении таблицы зависимость foreign key
Ну и не лишний plata id primary key

← →
SQLEXPRESS (2011-07-06 17:19) [11]

записей в обеих таблах? по отдельности

← →
dest81 (2011-07-06 17:23) [12]

> SQLEXPRESS

В табл. dogovor 10000, в табл. plata выше 20000

← →
Inovet © (2011-07-06 17:30) [13]

> [12] dest81 (06.07.11 17:23)
> В табл. dogovor 10000, в табл. plata выше 20000

Это мало, должно всё летать.

← →
dest81 (2011-07-06 17:36) [14]

> Inovet © (06.07.11 17:18) [10]
>
> На dogovor id в определении таблицы primary key
> На plata id_dg лучше сразу указать в определении таблицы
> зависимость foreign key
> Ну и не лишний plata id primary key

Соврал, счас посмотрел небыло только вторичного ключа.

на Pentium Dual T2390 1.86 GHz 29 мин

← →
dest81 (2011-07-06 17:40) [15]

Всем пасибо!

После добавления форинкея 30 мс

← →
Inovet © (2011-07-06 17:40) [16]

> [14] dest81 (06.07.11 17:36)
> небыло только вторичного ключа

Такой теперь есть?
plata id_dg

← →
Inovet © (2011-07-06 17:40) [17]

> [15] dest81 (06.07.11 17:40)
> После добавления форинкея 30 мс

Ну вот

← →
dest81 (2011-07-06 17:41) [18]

Нидумал что форинкей так влияет (все-таки индексы рулят)

← →
Inovet © (2011-07-06 17:43) [19]

> [18] dest81 (06.07.11 17:41)
> Нидумал что форинкей так влияет

Ну так а как поиск будет без ключа? на каждую запись из первой таблицы полный перебор второй.

← →
tesseract © (2011-07-06 17:44) [20]

> Нидумал что форинкей так влияет (все-таки индексы рулят)

http://citforum.ru/database/osbd/contents.shtml

Обретай дзен.

← →
SQLEXPRESS (2011-07-06 18:13) [21]

> форинкей так влияет (все-таки индексы рулят)

индекс почти всегда рулит при select
а правильный индекс - всегда :)
и почти все субд его создают при fkey

← →
Кщд (2011-07-06 18:47) [22]

>SQLEXPRESS (06.07.11 18:13) [21]
>а правильный индекс
критерии "правильности"?)

← →
картман © (2011-07-06 21:02) [23]

> а правильный индекс - всегда :)

хрен там

← →
engine © (2011-07-06 22:19) [24]

> критерии "правильности"?)

судя по плану, видимо

← →
Кщд (2011-07-06 23:50) [25]

>engine © (06.07.11 22:19) [24]
>судя по плану, видимо
общие слова
критерии не озвучены

в общем случае, прав картман: "хрен там"

например, в условиях:
1.
create table tmp (id number primary key, val number); create index i_tmp$val on tmp(val);;
2. таблица TMP содержит 1000 значений;
3. кол-во записей с val=1 равно 900, c val=2 равно, соответственно, 100;
4. выполняется запрос:
select t.* from tmp t where t.val = 1

Вопросы:
1. использование индекса будет оптимально?
2. это "правильный" индекс?

Т.е. "правильный" индекс - динамический?

← →
Кщд (2011-07-07 04:39) [27]

← →
SQLEXPRESS (2011-07-07 08:34) [28]

> Кщд (06.07.11 23:50) [25]

для этого запроса - нет

> критерии "правильности"?)

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

> SQLEXPRESS (07.07.2011 08:34:28) [28]

Он вредит всегда, где требуется преобразование индекса.

← →
SQLEXPRESS (2011-07-07 08:46) [30]

> Anatoly Podgoretsky © (07.07.11 08:36) [29]

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

И есть еще набор таблиц, в наследство получил, которые вообще без индексов, туда сбрасывают данные железки, insert там огого как отрабатывает. А вот selectа не дождешься. Они тоже ночью перегоняется в свои аналоги, с индексами.

> которые вообще без индексов
вообще вообще? или хотя бы праймари кей присутствует? он если сделать кластерным по авто инкременту практически не тормозит вставку.
а вот для селектов мог бы пригодиться... ну вот хотя бы при перебросе в другую таблицу запоминаешь последний перенесенный и следующий начинаешь с него. (и переброс по нему можно сделать порционным, по 3 тыс записей к примеру... т.к. когда количество переносимого переваливает какой то предел, ну возьмем 5 мл. записей то "разовый" в транзакции (целостность тоже нужна) начинает тормозить "сам то себе" (в дисковый кеш влазит))

Если значение нарастающие, то вообще не тормозит, поскольку физически его нет.

> Если значение нарастающие
это и имелось ввиду.
> по авто инкременту
но чтобы вообще, сомневаюсь. все таки время на операции с добавлением значения поля, + чуть больше данных в записи, тратится. т.е. если запись sql сервером идет по тому же алгоритму, что без него то + время операции. с другой стороны алгоритм (и ветка кода) может быть вообще другой, тогда возможен даже выигрыш... но в любом случае это будет несущественная дельта.

← →
SQLEXPRESS (2011-07-07 11:05) [34]

> вообще вообще? или хотя бы праймари кей присутствует?

Ну да, PK присутствует. Обязательно.
кроме него - никаких
Таблица без PK - недотаблица, имхо

select, sum как правильней Найти похожие ветки