Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.06.18;
Скачать: CL | DM;

Вниз

Даже не знаю как написать   Найти похожие ветки 

 
yaro   (2006-05-27 02:44) [0]

Всем салют!
Имеем:
Microsoft Access 2000, Delphi 5
Запрос вида: SELECT field0, (SELECT field1, fileld2 FROM table2 WHERE table2.field0 = table1.field0) FROM table1 WHERE [не важно]
Возвращает ошибку: типа нельзя возвращать из вложенного запроса более чем одно значение и приходится разбивать один вложенный запрос на два вложенных. Это не всегда удобно и быстро. Что делать?

Еще: Может мне под что-нибудь другое писать? Посоветуйте провайдер, желательно по принципу Client-Server, а не File-Server с поддержкой Stored-процедур и чтоб не такой громоздкий был, как Microsoft SQL-сервер, в котором от нормального приложения одно название осталось (весь под виртуальную машину написан, ставит кучу лабуды типа FrameWork"ов и тому подобное.


 
yaro   (2006-05-27 02:50) [1]

в Продолжение "ЕЩЕ":
В Ацессе мне нравится, что интерфейс работы с таблицами довольно удобный (со всеми описаниями, возможностью создания групп и так далее, что не маловажно при разработке, когда проэкт большой и таблиц не меньше 50 очень просто "потеряться").

Очень интересно узнать о достоинствах и недостатках других распространенных БД.

Заранее спасибо.


 
yaro   (2006-05-27 03:15) [2]

Еще одно уточнение:
Provider = Microsoft.Jet.OLEDB.4.0
я так понимаю, что проблема именно провайдера, а не самого Эксеса правильно?

При подключении к провайдеру что происходит? Сам провайдер у меня на машине лезет в сеть, открывает файл базы данных, если он не занят конечно (кстати, очень неудобно, что при выполнении задач в прелах одной транзакиции begintrans...committrans, а задача может выполняться долго, никто другой не может получить доступ к базе данных), делает что надо и говорит ответ? ЭТО ЖЕ БЕШЕНАЯ ЗАГРУЗКА СЕТИ!!!!!
Как с этим бороться?


 
ЮЮ ©   (2006-05-27 08:35) [3]


> SELECT field0, (SELECT field1, fileld2 FROM table2 WHERE
> table2.field0 = table1.field0) FROM table1 WHERE [не важно]


> я так понимаю, что проблема именно провайдера, а не самого
> Эксеса правильно?


Нет, это непонимание SQL. Ни один правильный сервер не должен браться за такое SQL предложение.
Построй в Access запрос на выборку полей из двух связанных таблиц и сравни правильный синтаксис со своим.


 
sniknik ©   (2006-05-27 09:04) [4]

> что при выполнении задач в прелах одной транзакиции begintrans...committrans, а задача может выполняться долго,
> никто другой не может получить доступ к базе данных
еще одно непонимание принципов работы с sql сервером. по правильному задача может выплнятся сколь угодно долго, но транзакция открыватся только на минимальное время т.е. на время сохранение результата.

> ЭТО ЖЕ БЕШЕНАЯ ЗАГРУЗКА СЕТИ!!!!!
> Как с этим бороться?
ну не такая уж и бешенная. а боротся не надо, надо просто брать и использовать sql сервер, любой, тот же mssql, и использовать правильно, а то непонимая принципов клиент серверной технологии можно сделать еще более "БЕШЕНУЮ ЗАГРУЗКУ" (легко кстати, достаточно бездумно адаптировать любое файл серверное приложение под sql сервер, не трогая основ "файл серверности").

p.s. если ты думаеш что проблема в "чемто", подойди к зеркалу, она в нем отражается... с вероятностью 99,8%.


 
yaro   (2006-05-27 13:07) [5]

ЮЮ: Это был до ужаса упрощенный пример, зачем придираться?
Я, вроде ясно выразился, что необходимо из подзапроса возвращать более чем одно значение.
Реальный запрос выглядит так (вернее его участок):

 "SELECT [Накладные].Код, " +
 "       (SELECT Дата FROM [Состояния накладных] WHERE [Состояния накладных].Код = (SELECT MAX(Код) FROM [Состояния накладных] WHERE Накладные.Код = [Состояния накладных].Накладная)) as D, " +
 "       [Типы накладных].Название, " +
 "       [Sclad1].Название, " +
 "       [Sclad2].Название, " +
 "       [Основания].Название, " +
 "       (SELECT Состояние FROM [Состояния накладных] WHERE [Состояния накладных].Код = (SELECT MAX(Код) FROM [Состояния накладных] WHERE Накладные.Код = [Состояния накладных].Накладная)), " +
 "       [Типы накладных].Направление, " +
 "       [Типы накладных].Код, " +
 "       [Типы накладных].[Сегмент состояния] " +
 "FROM   [Накладные], " +
 "       [Типы накладных], " +
 "       [Склады] as Sclad1, " +
 "       [Агенты] as Sclad2, " +
 "       [Основания] " +
 "WHERE  [Накладные].Тип = [Типы накладных].Код " +
 "   and [Типы накладных].Связь = 0 " +
 "   and [Sclad1].Код = [Накладные].Склад " +
 "   and [Sclad2].Код = [Накладные].Зависимый " +
 "   and [Основания].Код = Накладные.Основание ";


теперь внимательно присмотритесь к строкам (SELECT Дата ... и (SELECT Состояние...

мне пришлось писать два вложенных запроса, вместо одного (SELECT Дата, Состояние...


 
yaro   (2006-05-27 13:11) [6]


> транзакция открыватся только на минимальное время т.е. на
> время сохранение результата.


Согласен.


> если ты думаеш что проблема в "чемто", подойди к зеркалу,
>  она в нем отражается... с вероятностью 99,8%.


А вот это уже наезд. На себя посмотри.


 
yaro   (2006-05-27 13:14) [7]

Я, ксати, не пронял. а где моя анкета? Небыл тут всего два или три года, а уже анкету стерли. (это было еще тогда, когда сайт назывался delphi-mastak, вроде так.)


 
yaro   (2006-05-27 13:19) [8]

Да, кстати, с SQL-м знаком всего месяц. Раньше он мне просто не нужен было, а тут резко понадобился.
----------------

> sniknik


Издеваться всегда легче, чем помочь. и проблема тут НЕ ВО МНЕ, а в провайдере!!! А провайдер Microsoft.Jet.OLEDB.4.0!!!!! Может есть что-то получше, а то я в них вообще не шарю.


 
sniknik ©   (2006-05-27 14:07) [9]

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

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

> и проблема тут НЕ ВО МНЕ, а в провайдере!!!
в каком таком провайдере? да ни один sql сервер не выполнит подобного запроса, он противоречит принципам sql, т.е. по твоему проблема тогда значит в неправильных принципах по которым его разрабатывали, а не в тебе который их не хочет изучать? и хочет чтобы срабатывал любой написанный бред но так как хочется а не как написано... не бывает такого.

> Может есть что-то получше, а то я в них вообще не шарю.
лучше нет, есть более или менее подходящие под конкретную задачу. под задачу нахождения чего либо понимающего запрос из [0] не подходит ни один sql сервер. т.е. вопрос закрыт так понимаю...? т.к. себя "виновными" не признаем, а все sql сервера будут отказываться от выполнения твоего "правильного" запроса... замкнутый круг, однако.


 
yaro   (2006-05-27 16:24) [10]

> в каком таком провайдере? да ни один sql сервер не выполнит подобного запроса

почему же ... Оракл прекрасно все выполняет и Microsoft Jet выполняет, только оракл может из подзапроса 2 значения (да сколько угодно) выдать (заметь, не множество в таблице, а два единичных значения!!!), а Джет, почему-то говорит, что "больше одного не выдам, можешь не просить".
А таблица [Состояния накладных] очень-и-очень большая!!!!!! И мне неинтересно, чтобы машина выполняла филькину работу, выполняя абсолютно аналогичный запрос.

Ладно понял я все. Я и спрашивал-то для профилактики. И вижу, что самый главный ответ - это он противоречит принципам sql, т.е. по твоему проблема тогда значит в неправильных принципах по которым его разрабатывали, а не в тебе который их не хочет изучать? А SQL я понимаю прекрасно, что такое перемножение матриц тоже знаю, так что не надо из меня идиота делать. НИКАКИМ ПРИНЦИПАМ SQL МОЙ ЗАПРОС НЕ ПРОТИВОРЕЧИТ и самое интересное - работает. Может он притиворечит чему-либо, но только в рамках Вашей компетентности, sniknik.


 
sniknik ©   (2006-05-27 17:31) [11]

> почему же ... Оракл прекрасно все выполняет
не буду спорить, не в курсе насчет oracle... к счастью. ;)

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

> НИКАКИМ ПРИНЦИПАМ SQL МОЙ ЗАПРОС НЕ ПРОТИВОРЕЧИТ и самое интересное - работает.
ye это ты вреш. я могу согласится по поводу oracle, т.к. не знаю его достаточно, но это похоже исключение, остальные не дадут впихнуть на место одной переременной список. (да и oracle врядли, скорее он переделывает это в стандартный join)

> Может он притиворечит чему-либо, но только в рамках Вашей компетентности, sniknik.
моя компетентность не позволяет мне отвечать на незаданные вопросы/невысказанные желания/телепатемы/"на слабо"/а также тем кто игнорирует советы.


 
Johnmen ©   (2006-05-27 19:56) [12]


> НИКАКИМ ПРИНЦИПАМ SQL МОЙ ЗАПРОС НЕ ПРОТИВОРЕЧИТ


Блажен, кто верует!


 
yaro   (2006-05-27 19:58) [13]


> > НИКАКИМ ПРИНЦИПАМ SQL МОЙ ЗАПРОС НЕ ПРОТИВОРЕЧИТ и самое
> интересное - работает.
> ye это ты вреш. я могу согласится по поводу oracle, т.к.
>  не знаю его достаточно, но это похоже исключение, остальные
> не дадут впихнуть на место одной переременной список. (да
> и oracle врядли, скорее он переделывает это в стандартный
> join)


Еще раз говорю - это НЕ СПИСОК, а ДВЕ ПЕРЕМЕННЫЕ!!!!!!!!!!


 
yaro   (2006-05-27 20:01) [14]

Просто вложенный запрос должен возвращать не одну переменную, а две. вот именно потому, что "на каждую полученную запись" выполняется по запросу, а разница два запроса или один - это уже БОЛЬШАЯ разница.


 
Desdechado ©   (2006-05-27 21:17) [15]

> Оракл прекрасно все выполняет, только оракл может из подзапроса
> 2 значения (да сколько угодно) выдать (заметь, не множество в таблице,
> а два единичных значения!!!)
только что попробовал на Ora 9.2 EE - гон чистой воды, именуемый
"ORA-00913: слишком много значений"
Оракл может сделать SELECT ... FROM ( SELECT ... ), но описанный выше запрос - бред.
Если не умеешь соединять таблицы во WHERE, то незачем лепить это в SELECT.


 
sniknik ©   (2006-05-27 21:25) [16]

> Еще раз говорю - это НЕ СПИСОК, а ДВЕ ПЕРЕМЕННЫЕ!!!!!!!!!!
а разрешена одна, что в "длинну", что в "высоту". любое отступление - противоречие.

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

> а разница два запроса или один - это уже БОЛЬШАЯ разница.
а один запрос на все записи (нормальный вариант присоедененного запроса) или один на каждую запись (твой желаемый вариант, подо что sql сервер ищется) это просто ОГРОМЕННАЯ разница... по количеству записей может быть в миллион раз чаще выполняется, что там мелочь с двумя всего в два раза... счаслив должен быть, что Jet такой глупости не позволяет свершится вместо "наездов" на него. скорее oracle этого заслуживает (хотя говорил уже, сомнения у меня что он так делает, даже если синтаксис разрешон, то скорее всего запрос движком оптимизируется до джойна).
но счастья может  и не быть, пациент упорствует....


 
sniknik ©   (2006-05-27 21:29) [17]

Desdechado ©   (27.05.06 21:17) [15]
> только что попробовал на Ora 9.2 EE - гон чистой воды, именуемый ...
упс, сорри. я то предпологал что правда может, по незнанию даверял людям...
т.что мой "гон" на oracle в [16] считать недействительным. здесь он не виноват... ;)


 
yaro   (2006-05-28 03:09) [18]

Ребята, понял, значит мне наврали... (про оракл, сказал человек, у которого я консультировался) значит больше одного никак? А жаль. ну ладно. А в WERE все объединять будем уже при оптимизации. К тому же там не так-то просто объединить в данной ситуации, можно если создавать лишний столбец в двух таблицах, тогда проще. А так я решил это на потом оставить.

Прошу прощения у всех, кого обидел.

Вот объясните мне тупому, как вот это написать одним запросом?
(SELECT Дата FROM [Состояния накладных] WHERE [Состояния накладных].Код = (SELECT MAX(Код) FROM [Состояния накладных] WHERE [Состояния накладных].Накладная = <значение>))


 
sniknik ©   (2006-05-28 10:32) [19]

> К тому же там не так-то просто объединить в данной ситуации, можно если создавать лишний столбец в двух таблицах, тогда проще.
это не просто, а очень просто... если последуеш совету ЮЮ ©   (27.05.06 08:35) [3] и будеш строить запрос в аксесс, в мастере. там вообще все визуально, один раз перетащить мышкой связь, после выбрать отображаемые поля. вуаля, запрос готов.

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


 
yaro   (2006-05-29 00:11) [20]

нО ТАБЛИЦЫ-ТО В аКСЕСЕ не связаны!!!!! Я аксес использую как конструктор и менеджер таблиц (и то - второе - реже). Все остальное программа делает.
И одним запросом то, что мне надо не сделаешь. Есть две таблицы: "Накладные" и "Состояния накладных" Накладные - это шапка накладной с основными параметрами, каждая накладная может быть в одном из состояний, причем состояния необходимо сохранять в истории. т.е. в каком состоянии сейчас накладная показывает этот запрос:

(SELECT Состояние FROM [Состояния накладных] WHERE [Состояния накладных].Код = (SELECT MAX(Код) FROM [Состояния накладных] WHERE [Состояния накладных].Накладная = <значение>))


А большой запрос, указанный в yaro   (27.05.06 13:07) [5], отображает список всех накладных (ну почти, там юнионом объединены три таких запроса с разными источниками и приемниками, но это не важно).

И я никак не пойму, как сделать это все в одном запросе объениняя в WHERE??????

> вот именно это нормально написано, именно так это и используют


теперь у меня вопрос: причем тут

> Построй в Access запрос на выборку полей из двух связанных таблиц и сравни правильный синтаксис со своим.


P.S. В Аксесе никогда запросы не строил и не собираюсь, для меня - это тупой менеджер таблиц и не более. Вот эти связанные таблицы - это бред самый настоящий. База данных должна хранить данные и выдавать их в разных вариациях согласно запросу. В одном варианте у меня данные означают одно, в другом - те же данные - другое. И это - нормально, я считаю. Поэтому Построй в Access запрос на выборку полей из двух связанных таблиц даже не собираюсь делать.


 
sniknik ©   (2006-05-29 00:31) [21]

> P.S. В Аксесе никогда запросы не строил и не собираюсь, для меня - это тупой менеджер таблиц и не более.
зря. он грамотнее тебя в этом отношении... и если набрать визардом нужное обьеденение и посмотреть синтаксис принципиально невозможно, то... в общем разговор окончен. пациент не выжил. ;(


 
ЮЮ ©   (2006-05-29 03:01) [22]

SELECT
 t1.field0, t2.field1, t2.fileld2
FROM
 table1 t1
 [LEFT] JOIN  table2 t2 ON t1.field0 = t2.field0
WHERE [не важно]

если связь 0..N и тебя интересуют записи из Table1 даже если нет соответстыующей записи в Table2 стоит использовать LEFT JOIN. В остальных случаях (связь 1..N или нас не интересуют  записи из Table1 если нет соответстыующей записи в Table2)  стоит использовать просто JOIN


 
MsGuns ©   (2006-05-29 09:37) [23]

>yaro   (29.05.06 00:11) [20]
>нО ТАБЛИЦЫ-ТО В аКСЕСЕ не связаны!!!!!

Первое. Рискуя быть обложенным, все же наберусь "хамства" и посоветую с недельку-другую "завязать" с программингом и основательно проштудировать "теорию", хоть тот же хэлп по акцесу (Кстати, прекрасный "тренажер" для обучения SQL и понимания основ клиен-серверной технологии)

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


 
yaro   (2006-05-29 12:43) [24]


> Второе. Судя по примеру ("состояния" накладных), у автора
> не все в порядке и с пониманием проблематики. Если введена
> такая сущность, то  явно, что у нее фиксированное и явно
> небольное кол-во возможных значений. Причем значения скорее
> всего альтернативны друг другу. В этом контескте сабжевый
> запрос выглядит нелепо не только с т.зр. скл-сервера, но
> и нормального человека, элементарно знакомого с предметом
> (учет товаро-материальных ценностей).


Явно НЕ фиксированное! кол-во возможных значений, при этом значения НЕ АЛЬТЕРНАТИВНЫ друг другу, а логически продолжаемые, можно и так сказать.

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

Ну спасибо. у меня третий год уже своя фирма.


 
yaro   (2006-05-29 12:49) [25]

и понятие "состояние накладных" и еще около 10-20 других понятий, отличных от обычного учета (скажем 1С, базовые кон-ции) именно потому, что другие готовые продукты не могут в ПОЛНОЙ мере вести учет с учетом некоторых оссобенностей работы фирмы.


 
MsGuns ©   (2006-05-29 12:56) [26]

>yaro   (29.05.06 12:43) [24]
>Явно НЕ фиксированное! кол-во возможных значений, при этом значения НЕ АЛЬТЕРНАТИВНЫ друг другу, а логически продолжаемые, можно и так сказать.

Не знаю, что имелось в виду под "состоянием накладных", но, очевидно не типа "Вводится, введена, проведена, откачена...". Надо бы уточнить.

>Ну спасибо. у меня третий год уже своя фирма.

Хоть 20 лет и 120 фирм. К проектированию БД это никакого отношения не имеет.

Немного по теме:
"Накладные" по сути охватывают все виды материальных документов, сопровождающих и юридически подтвержающих перемещение ТМЦ внутри организации, в том числе и документы, называемые совсем не "накладными" (например, "акт списания", "акт переоценки", "инвентраризационная ведомость" и т.д.)
Различают внешние и внутренние, приходные и расходные, оперативные и накопительно-аналитические.

Что Вы понимаете под "накладными", у которых есть какие-то "состояния", остается тайною за семью печатями. Усугубленной мутной логикой запросов.


 
Desdechado ©   (2006-05-29 13:35) [27]

> нО ТАБЛИЦЫ-ТО В аКСЕСЕ не связаны!
А вот это большой прокол с точки зрения проектирования БД.
Таблицы - это некоторые сущности, которые вступают в отношения (связи) между собой. И если таблицы не связаны, то получается как в фейерверке - вроде из одного патрона, но каждый огонек сам по себе. А это бесмыслица.

Поэтому присоединюсь к [23], пункт 1.



Страницы: 1 вся ветка

Текущий архив: 2006.06.18;
Скачать: CL | DM;

Наверх




Память: 0.55 MB
Время: 0.012 c
15-1147673699
Сергей И
2006-05-15 10:14
2006.06.18
Информация по литературе


3-1145887884
Квэнди
2006-04-24 18:11
2006.06.18
Dbexpress Delphi 2006


15-1148230125
RUNaum
2006-05-21 20:48
2006.06.18
psql и че-то не допирает...


15-1148274904
Александр Иванов
2006-05-22 09:15
2006.06.18
Сумма прописью


2-1149086654
Pascal-men
2006-05-31 18:44
2006.06.18
Простите что не в тему!





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский