Надо запихнуть в столбец данные из разных столбцов

← →
linx (2003-09-22 11:41) [0]

Подскажите как это сделать.
Я пока вижу 1 способ - реализовать это через хранимую процедуру, а потом использовать ее в операторе SELECT. Но проблема в том, что SELECT в самой хранимой процедуре генерится динамически, т.е. реально я должен создать несколько (достаточно много, причем объемных) хранимых процедур типа
CREATE PROCEDURE P1
...
BEGIN
FOR SELECT1
...
END

CREATE PROCEDURE P1
...
BEGIN
FOR SELECT2
...
END

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

← →
Zacho (2003-09-22 11:45) [1]

Опиши задачу более конкретно, а то "запихнуть в столбец данные из разных столбцов " - не понятно, что именно надо.

← →
linx (2003-09-22 12:38) [2]

Наверное действительно не очень понятно...
Итак, у меня два типа клиентов - физ.лица и юр. лица. Мне нужны поля фамилия из таблицы физ.лица и название организации из таблицы юр.лица.
Есть еще одна важная таблица - контракты. Я пытаюсь получить данные по контрактам, но так, чтобы в них фигурировали фамилия или название организации соответствующих клиентов. Ну, если клиент физ.лицо, то фамилия, если юр.лицо, то название организации. Фамилии и названия организаций я хочу за... поместить в один столбец, чтобы на экране в результате получилась таблица с полями, например:

NumberContract DateStartService Familia/NameOrganisation

Фух, кажется теперь должно быть понятно...

← →
Johnmen (2003-09-22 12:41) [3]

Сцепление строковых значений : ||

← →
Deniz (2003-09-22 13:01) [4]

Или ХП, причем она одна, или ...
1. create procedure ... returns ( NumberContract integer, ... StrName varchar(...)) <--- Familia/NameOrganisation declare TypeOfCntr integer; ... for select NumberContract, ..., TypeOfContract from Contract into :NumberContract, ..., :TypeOfCntr do begin if (TypeOfCntr = 1) then select Familia from SprFiz where id = :... into :StrName; else select Familia from SprYr where id = :... into :StrName; suspend; end;

Ну там сам доработаешь.
Второй вариант select & union

← →
MsGuns (2003-09-22 13:20) [5]

>linx © (22.09.03 12:38) [2]
>поместить в один столбец, чтобы на экране в результате получилась таблица с полями..

Если это надо только для отображения, то событие OnGetText филдов датасета позволяет вытворять с инфой что душе угодно (а в совокупности с OnDrawColumnCell и картинки можно настрозючить) - зачем для этого писАть какие-то замудренные ХП и вообще "беспокоить" сервер ?

← →
Rem (2003-09-22 16:19) [6]

SELECT
[Фамилия клиента], [Номер контракта]
FROM
[Физические лица]
UNION
SELECT
[Название организации], [Номер контракта]
FROM
[Юридические лица]

← →
Rem (2003-09-22 16:19) [7]

← →
linx (2003-09-22 16:33) [8]

Deniz, ты все правильно понял, я про этот вариант(№1) и говорю. Проблема в том, что в строке
"for select NumberContract, ..., TypeOfContract from Contract"
этот самый select должен динамически изменяться в зависимости от данных, которые вводит пользователь. Получается что каждый раз, когда мне надо получить набор данных я должен сгенерить нужный запрос, потом создать или изменить под этот запрос хранимую процедуру, потом на основе полученной ХП активировать новый запрос. Витиевато как-то...
Поясни пожалуйста про select & union, что-то я и так и сяк...

← →
linx (2003-09-22 16:36) [9]

Ой, пока я писал вопрос, тут уже Rem ответил. Сейчас разберусь.

← →
MsGuns (2003-09-22 17:02) [10]

>linx © (22.09.03 16:36) [9]
>Ой, пока я писал вопрос, тут уже Rem ответил. Сейчас разберусь.

Лучше не надо.

← →
MsGuns (2003-09-22 17:08) [11]

ИМХО, вопрос возник от не до конца продуманной модели БД. Зачем физ и юр лиц растаскивать по разным таблицам ? Мало того, что вылазят всякие негаразды типа сабжа при выборках, так еще если есть те, кто одновременно и то, и другое (а это запросто), то что прикажете - в двух таблицах его держать ? Кроме того, всю кухню реквизитов надо также двоить.

← →
linx (2003-09-26 11:18) [12]

2MsGuns
"Зачем физ и юр лиц растаскивать по разным таблицам ?"

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

"еще если есть те, кто одновременно и то, и другое (а это запросто),"
Бррррр, это как? Поясни пожалуйста, для меня это важно.

← →
Sergey13 (2003-09-26 11:42) [13]

2linx © (26.09.03 11:18) [12]
>Ну, я так подумал, если полей общих у них почти нет, то правильнее будет поместить их в разные таблицы.
Правильнее только для экономии дискового пространства. Удобнее все в одной таблице.

>"еще если есть те, кто одновременно и то, и другое (а это просто),"
>Бррррр, это как? Поясни пожалуйста, для меня это важно.
Не заморачивайся. По всякому дважды надо прописывать если так, ИМХО. Ибо это разные контрагенты.

← →
don-do (2003-09-26 13:19) [14]

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

Полей общих найти можно много, например:
ф.,и.,о.,Инн,Юр.адрес, Факт.Адрес,Банк и др
если поля несут разную сущность, то их тоже можно объединять.
Вобщем на рассмотрение разработчика, лишь бы небыло путаницы.

← →
Sandman25 (2003-09-26 13:29) [15]

Да все правильно он спроектировал. Общие поля в одну таблицу, разные поля еще по двум таблицам.
Причем ссылочную целостность даже легче соблюдать получается - если ссылка может быть только на юридическое лицо, то ссылаемся на таблицу "юриков", если на любое - то на общую таблицу.

← →
MsGuns (2003-09-26 13:53) [16]

>linx © (26.09.03 11:18) [12]
>Ну, я так подумал, если полей общих у них почти нет, то правильнее будет поместить их в разные таблицы.

Это как это нет ? Я бы сказал, что общих полей у них не меньше, чем отличающихся (Адрес, Наименование, Телефон, Сальдо и т.д.)

>"еще если есть те, кто одновременно и то, и другое (а это запросто),"
Бррррр, это как? Поясни пожалуйста, для меня это важно.

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

>Sandman25 © (26.09.03 13:29) [15]
Очень спорная ремарка.

← →
linx (2003-09-26 14:47) [17]

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

← →
MsGuns (2003-09-26 16:04) [18]

>linx © (26.09.03 14:47) [17]
>Кстати в книжке было сказано, что если в таблице есть поля, которые заведомо всегда будут пустые - то это плохо

Плохо когда прочитанное в книжке воспринимается как догма. Ты слышал про зарезервированные поля ? Так вот, в БД они тоже бывают. Например, клиент мне говорит, что у него один склад и ему на фиг не нужна бухгалтерия. Новичек так и сделает, в то время как опытный разработчик все равно в БД заложит соответствующие сущности, даже портатив на это бОльшее время.
Через полгода клиент скажет, что у него появился новый склад, да и бух недоволен, что в компе нет "его" инфы. Новичек будет переделывать прогу заново, опытный же только сделает вид, открыв в интерфейсе новые поля и фичи.
Вообще, если ты чувствуешь, что проблему знаешь не лучше заказчика, то надо не садиться программить, а разбираться дальше.
Все ошибки, заложенные в проекты на этапе разработки, на 99% следствие нарушения этого принципа.

Главный принцип хорошего программиста (разработчика):

Знание предмета лучше заказчика и умение предугадывать его возможные желания.

← →
Alex_Raider (2003-09-26 16:45) [19]

2MsGuns:

"Не размножай сущностей без необходимости".

Оккам

← →
Sandman25 (2003-09-26 16:51) [20]

[16] MsGuns © (26.09.03 13:53)
>Очень спорная ремарка.

Можно поконкретнее? В чем проблема?

Не может одно и то же лицо быть и физическим, и юридическим. А вот иметь несколько счетов может, и при операции с разными счетами могут быть разные правила. Именно так у нас и сделаны. Причем клиенты классифицируется не просто как юрид./физич., а произвольным образов - используется древовидный справочник с возможностью множественной привязки.

← →
Rem (2003-09-26 17:35) [21]

> MsGuns © (26.09.03 13:53) [16]

И все же, Иванов как физ. лицо и как юр. лицо - разные вещи. Интересно, что скажет ТЕБЕ в лицо Иванов, когда к нему прийдут из налоговой с перекрестной проверкой и, по результатам сданной ТОБОЮ отчетности окажется, что он превысил предел оборота для ЧП-единщика на 2 доллара, купив, как физ. лицо, в твоем магазине ребенку упаковку Памперсов? А по ТВОИМ отчетам это будет его бизнес-оборот. И попробуй разберись. Кому штрафы платить: Иванову или тебе? Поэтому учет по физ. и юр. лицам надо все же вести отдельно, а случаи совпадения физ. и юр. лиц обрабатывать отдельно, ибо, все же, это ЧАСТНЫй случай.

← →
linx (2003-09-26 17:48) [22]

Народ, тут проблема у меня, а как же ввести сортировку в запрос типа:

SELECT
[Фамилия клиента], [Номер контракта]
FROM
[Физические лица]
UNION
SELECT
[Название организации], [Номер контракта]
FROM
[Юридические лица]

???

Так то все получилось, но без сортировки мне нельзя.

← →
Sandman25 (2003-09-26 18:02) [23]

...
order by 1, 2

← →
linx (2003-09-26 18:10) [24]

2Sandman25 Да, все работает. :)

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