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

1. dogovor
id
name

2. plata
id
id_dg
suma

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

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

В форум по ИБ

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

Ключевое слово 'правильнее'
Я делаю так
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
очень быстро

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

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

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

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

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

> Inovet ©


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

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


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

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

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

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

> SQLEXPRESS


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

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

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

> 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 мин

Всем пасибо!

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

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

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

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

Ну вот

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

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

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

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


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

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

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

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

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

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

хрен там

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

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

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

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

например, в условиях:
1.

;
2. таблица TMP содержит 1000 значений;
3. кол-во записей с val=1 равно 900, c val=2 равно, соответственно, 100;
4. выполняется запрос:



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

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

>engine ©   (07.07.11 00:00) [26]
если вопрос адресован мне, то что значит "динамический" индекс?

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

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


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

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

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

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

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

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

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

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

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

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

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

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