недавно перешел на MS SQL и после Paradox'a мощь немного ошеломляет...
а собственно вопрос такой можно ли составлять запросы такого вида:

например надо получить из таблицы А все ряды, про которые в таблице B (в поле table_a_id) нет данных (т.е. чтобы запрос вида SELECT id from B WHERE table_a_id=A.id был nil) ?

или например выбрать все данные из таблицы в которых поле с датой и сегодняшней датой различается на N-ное количество дней?

судя по всему все мои вопросы сводятся к одному, как составлять более сложные запросы чем select * from sometable
есть ли краткий on-line справочник по синтаксису?

Вот один из кучи возможных вариантов.

Код

Select * From A Where ID Not In (Select ID From B)

Вообще можно почти все (трудно придумать то, чего нельзя)

Цитата(z @ 9.9.2005, 21:24)

есть ли краткий on-line справочник по синтаксису?

MSDN -> Enterprise Development -> Windows Server System -> Microsoft SQL Server -> ... ->Transact-SQL Reference

ИМХО, шибко пользительно для тренировки и изучения
Упражнения по T-SQL

Цитата(Akina @ 9.9.2005, 11:49)

Вообще можно почти все (трудно придумать то, чего нельзя)

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

Цитата(Vit @ 16.9.2005, 17:32)

Могу составить боооольшой список

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

Цитата(Akina @ 16.9.2005, 08:01)

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

С учётом того что можно положить курсор типа "Select * From MyTable" с тем чтобы построчно пройти таблицу при наличии возможности вызовов внешних DLL то действительно можно сделать всё, но многие вещи реализуются исключительно сложно, громоздко, работают медленно и отбирают много ресурсов.

Цитата

и при этом находится в рамках реляционной модели (без идиотских просьб "взять значение из предыдущей ячейки")?

Модель - лишь идеал, который помогает стройно реализовать некую идеальную ситуацию. Реалии таковы, что хорошая модель охватывает 95-99% ситуаций, а остальные 1-5% реализуются исключительно геморройно преодолевая недостатки модели какими-нибудь окольными путями. Года 2 назад мне пришлось решать эту "идиотскую просьбу" из предыдущей ячейки, на тот момент мне ситтуация не казалась не смешной и идиотской, а пришлось потратить неимоверные усилия чтоб её решить, причём таблицы были вполне нормализованы и достаточно логичны... и задача оказалась вполне логичной... Если есть интерес могу привести этот пример.

Цитата(Vit @ 16.9.2005, 20:48)

Если есть интерес могу привести этот пример

Надеюсь, это не будет слишком оффтопно?

Таблица полётов на самолёте людей. Примерный вид:

Одно путешествие выглядит как :

1Сегмент - из Чикаго до Майями отлёт 1.2.2005
3Сегмент - из Майами до Детройта отлёт 2.3.2005
7Сегмент - из Детройта до Чикаго отлёт 5.6.2005

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


1Сегмент - из Чикаго до Майями отлёт 1.2.2005
3Сегмент - из Майами до Детройта отлёт 2.3.2005
5Сегмент - фиктивный
7Сегмент - из Детройта до Чикаго отлёт 5.6.2005

В таблице это выглядит как

Путешествие1|1|Дельта|Чикаго|Майами|1.2.2005
Путешествие1|3|Дельта|Майами|Детрой|2.3.2005
Путешествие1|5|Фиктив|
Путешествие1|7|Дельта|Детройт|Чикаго|5.6.2005

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

PS. Задача довольно сильно упрощена, я попытался передать смысл и самый минимальный объём информации, на самом деле участвовало гораздо больше таблиц и параметров, но реально камнем преткновения стала такая ситуация.