Есть таблица
field1 данные
field2 код записи
num autoinc
В таблице данные хранятся так сказать по записям, то есть. предположим необходимо ввести в БД запись Фамилия, имя отчество.
Реально вводиться в татлицу 3 строки
таблица
field1 field2 num
Фамилия 1 1
Имя 1 2
Отество 1 3
Как бы теперь это отобразить в запросе как
Запись ФИО
1 Фамилия Имя отчество
Здравствуйте, ironwit, Вы писали:
I>Как бы теперь это отобразить в запросе как I>1 Фамилия Имя отчество
Правильный ответ — переделать схему; она, мягко говоря, неудачна. А так —
select
coalesce (families.value, '???' ) || ' '
coalesce (names.value, '???' ) || ' '
coalesce (surnames.value, '???' ) as fio
from
(select * from names where typ = 1 and id = :id) families,
(select * from names where typ = 2 and id = :id) names,
(select * from names where typ = 3 and id = :id) surnames
Здравствуйте, CheG, Вы писали:
CG>Здравствуйте, ironwit, Вы писали:
CG>м-мм интересно как ты различаешь где фамилия, а где отчество??? Или считается, что первым обязательно идет имя, потом фамилия и тд???
да нет, там еще в таблице для каждого свой код есть, для которого в еще одной таблице есть текстовое наименование что это. Юзер выбирает себе наименование отчета, по номеру отчета выбираются все его составляющие и заполняются данными. В теории, пока такое только реализовываю...
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, ironwit, Вы писали:
I>>Как бы теперь это отобразить в запросе как I>>1 Фамилия Имя отчество
S>Правильный ответ — переделать схему; она, мягко говоря, неудачна.
как? Если необходимо хранить данные, про которые я заранее ничего не знаю. ФИО только для примера, а так может быть все что угодно... Hk.c надо дать возможность юзеру создавать свои наборы данных.
S>А так -
S>
S>select
S> coalesce (families.value, '???' ) || ' '
S> coalesce (names.value, '???' ) || ' '
S> coalesce (surnames.value, '???' ) as fio
S>from
S> (select * from names where typ = 1 and id = :id) families,
S> (select * from names where typ = 2 and id = :id) names,
S> (select * from names where typ = 3 and id = :id) surnames
S>
Здравствуйте, ironwit, Вы писали:
S>>Правильный ответ — переделать схему; она, мягко говоря, неудачна. I>как? Если необходимо хранить данные, про которые я заранее ничего не знаю. ФИО только для примера, а так может
Зависит от задачи. Когда у меня в последний раз появилась такая необходимость, я просто дал пользователю инструмент создания и заполнения таблиц (естественно, со скрытыми техническими деталями), и, соответственно, пользовался метаинформацией оракла для интерфейса — например, введенное пользователем имя колонки хранилось в user_col_comments, откуда выводилось в интерфейс и откуда бралось реальное имя колонки для формирования sql.
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, ironwit, Вы писали:
S>>>Правильный ответ — переделать схему; она, мягко говоря, неудачна. I>>как? Если необходимо хранить данные, про которые я заранее ничего не знаю. ФИО только для примера, а так может
S>Зависит от задачи. Когда у меня в последний раз появилась такая необходимость, я просто дал пользователю инструмент создания и заполнения таблиц (естественно, со скрытыми техническими деталями), и, соответственно, пользовался метаинформацией оракла для интерфейса — например, введенное пользователем имя колонки хранилось в user_col_comments, откуда выводилось в интерфейс и откуда бралось реальное имя колонки для формирования sql.
у меня mysql, но хотелось бы все эт ореализовать как можно ближе к стандартному SQL, дабы облегчить перехеод с БД на БД.
Ну если это Оракл, то всё упрощается... Я бы сделал в этом случае три хранимые процедуры для извлечения Имени, Фамилии и Отества или пустые строки в случае отчутсвия онных, потом выборка типа
select
schema.package.proc1(table.cod) as name1,
schema.package.proc2(table.cod) as name2,
schema.package.proc3(table.cod) as name3
from schema.table where cod=in_cod
Здравствуйте, ironwit, Вы писали:
I>у меня mysql, но хотелось бы все эт ореализовать как можно ближе к стандартному SQL, дабы облегчить перехеод с БД на БД.
Хм. Как бы Вам сказать, Вы уже взялись за задачу, несколько превосходящую Ваши текущие знания. Я бы посоветовал Вам не усложнять ее еще больше размышлениями о нескольких серверах — это весьма сложная задача сама по себе. Более насущная задача — сделать программу хотя бы на MySQL так, чтобы сервер выдержал несколько десятков/сотен сложных запросов одновременно.
Здравствуйте, CheG, Вы писали:
CG>Ну если это Оракл, то всё упрощается... Я бы сделал в этом случае три хранимые процедуры для извлечения Имени, Фамилии и Отества или пустые строки в случае отчутсвия онных, потом выборка типа
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, ironwit, Вы писали:
I>>у меня mysql, но хотелось бы все эт ореализовать как можно ближе к стандартному SQL, дабы облегчить перехеод с БД на БД.
S>Хм. Как бы Вам сказать, Вы уже взялись за задачу, несколько превосходящую Ваши текущие знания. Я бы посоветовал Вам не усложнять ее еще больше размышлениями о нескольких серверах — это весьма сложная задача сама по себе. Более насущная задача — сделать программу хотя бы на MySQL так, чтобы сервер выдержал несколько десятков/сотен сложных запросов одновременно.
да там не планируется пока и нескольких десятков. Максимум это два-три в единицу времени.
Здравствуйте, ironwit, Вы писали:
I>да там не планируется пока и нескольких десятков. Максимум это два-три в единицу времени.
"Замужество, моя милая, не планируется; оно случается"
Смена (тем более, регулярная) БД — куда менее вероятный вариант, чем увеличение нагрузки. Собственно, любую программу, которая хоть чего-то стоит, тут же начинают нагружать по полной — это нормально.
Здравствуйте, ironwit, Вы писали:
S>>Хм. Как бы Вам сказать, Вы уже взялись за задачу, несколько превосходящую Ваши текущие знания. I>Нуууу, вот это как раз не страшно. Как мы еще учится то могем?
На это есть много ответов, в частности, небезызвестная фраза Моцарта: "Да, я в шесть лет написал симфонию. Но я ни у кого не спрашивал, как их писать".
Насчет страшного — варианты есть разные. Вопрос в том, что усложнять эту задачу дальше уже не стоит; при этом не будет ничего, кроме катастрофического роста вероятности сделать плохо.
