Не соображу, как более правильно создать следующий запрос:
есть TStringList, в каждой строке которой содержащий три значения для трех полей таблицы "Иванов / Иван / Иванович". Необходимо получить выборку, соответствую всем значениям TStringList, причем количество данных может быть несколько тысяч.
Думаю сделать так при помощи TRANSFORM :



Т.е. получается как то так. На сколько такой запрос верный? Или можно как то более красиво это сделать?

> причем количество данных может быть несколько тысяч.


Убил бы. Оперируй ID

> Оперируй ID

А каким образом? Я как раз понимаю, что делать такую выборку некузяво, но как из БД выбрать несколько тысяч человек по запросу?

Представь, какого размера будет запрос при тысячах строк..
Можно сохранить стринг лист в виде текстового csv-файла и указывать его как таблицу, которую просто джойнить с условием.
В соседней ветке это обсуждали: http://pda.delphimaster.net/?id=1319962304&n=1

Но есть подозрение, что в архитектуре косяк. Ибо зачем хранить тысячи ФИО в стринглисте?

> но как из БД выбрать несколько тысяч человек по запросу?


А ты точно уверен, что пользователю нужны все эти тысячи человек одновременно?
Практика показывает, что пользователю нужно то, что помещается в данный момент на экран.

> пользователю нужны все эти тысячи человек одновременно?


Да. Это специфика программы )) На самом деле там не фамилии, получиться должен итоговый список районов для определенной страны.
Т.е. выборка из общей БД такая: пользователь задает, данные о районах какой страны он хочет получить. В России допустим около 2800 районов.
И вот из БД нужно выбрать:
Страна - Россия, Область - [идет список выбранных областей], Район - [идет список выбранных районов]. Причем естественно необходимо учитывать, что допустим Ленинский или Октябрьский районы есть практически во всех областях.
Наверное как я понял, самое правильное

> охранить стринг лист в виде текстового csv-файла и указывать
> его как таблицу, которую просто джойнить с условием.

> Ega23  (31.10.2011 14:17:01)  [1]

Цикл смылс не имеет, первое условие уже выпоненено: 'where (0=0)'  + OR +
И дальнейшие условия уже не влияют.

where
позиция('$'+fam+' '+name+' ' + otch+'$',<целиковый_список_в_виде_текста_с разделителями-долларами>) > 0

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

> Убил бы. Оперируй ID
влезет больше
WHERE ID IN (1,2,3...,1000)

> 'where (0=0)'  + OR +


Тьфу, блин, очепятка. where (0=1), конечно.

> Т.е. выборка из общей БД такая: пользователь задает, данные
> о районах какой страны он хочет получить. В России допустим
> около 2800 районов.


3 запроса через мастер-деталь

> Страна - Россия, Область - [идет список выбранных областей],
>  Район - [идет список выбранных районов]. Причем естественно
> необходимо учитывать, что допустим Ленинский или Октябрьский
> районы есть практически во всех областях.

Отбить руки архитектору БД, если всё это в одной таблице хранится, если же в трёх разных, то ты неправильно понял или неправильно объясняешь задачу.

> Отбить руки архитектору БД, если всё это в одной таблице хранится
кладр... уже без кук? ;)

Не поминай это овно, КЛАДР наверное ключница делала. Может сейчас что то исправили, давно с ним не работал, но то, что я видел лет 5 назад это ППЦ. Создатель либо полный профан, причём с дикого бодуна писал и слово нормализация для него просто звук, либо с.ка вредитель.

Спасибо за советы. Думал вариант с текстовыми условиями будет проще, но поразмыслив, понял что нифига не проще.
Попробую более подробно объяснить задачу.
Есть база данных. Пользователю необходимо предусмотреть выборку по значениям практически ЛЮБЫХ комбинаций полей. Для примера:
в основной базе есть поля: Страна, Город, Район - текстовые поля. Поле Свойство1 - текстовое поле, принемающее одно из 10 значений, логические поля Подтверждение1, Подтверждение2.
В качестве значений выборки предполагается использовать вторую таблицу с полями Страна, Город, Район с введенными в нее нужными данными.
В итоге должна получится таблица
Страна, Город, Район, Значение1_Свойство1...Значение10_Свойство1,
где в строках Значение1_Свойство1...Значение10_Свойство1 прописано кол-во Подтверждение1/Подтверждение2.
Ранее все это я делал с помощью компонента VolgaTable. Но там просто приходилось перебирать все записи БД, и заносить данные в итоговую таблицу. Сейчас переделываю программу для работы с Access.

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

Тьфу, тьфу, тьфу!!! Забудь слово "база данных"!!! Нет такого! Какие есть ТАБЛИЦЫ??? Структуру их опиши и связи между ними! Твое описание похоже на вопрос: "У меня есть склад, где есть яйца, мука, соль, варенье и много всего. Как мне запросом выбрать пустые пирожки и занести туда начинку?"

> во всяком случае год назад
во блин, время летит... посмотрел свойства проекта, изменен - 19 февраля 2010 г. т.е. уже 2 года назад. ;(

> Какие есть ТАБЛИЦЫ???


В общем есть такие люди - радиолюбители. :) Раньше они вели аппаратный журнал (регистрация радиосвязей) на бумаге. Сейчас на компьютере.
Есть основная таблица, содержащая данные на каждую радиолюбительскую связь, куда вносятся Позывной, Имя, Город, Район, Страна ... <Еще некоторые специфические данные>, дале поля Диапазон и Модуляция, которыми проверена связь (выбираются из списка), логические поля Отсылки подтверждения и Получения подтверждения контакта.
Пользователю нужно иметь возможность увидеть (для получения радиолюбительских дипломов) допустим с какими странами из списка есть радиосвязь, или же с какими районами США и Канады. При этом слева идут названия стран или районов, а в качестве столбцов - разбивка по диапазонам.
Идея в том, чтобы пользователю дать возможность самому формировать условия выборки по нужным полям.
Вот как то так :)

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

Вообще почитай о нормализации БД, это крайне полезно. Заведи правило - не работать с БД, пока не приведёшь её к третьей нормальной форме. Потом это войдёт в привычку, втянешься и пойдёт поедет. Бывало по нескольку дней сидишь, но до пятой формы дотянешь :)

> куда вносятся Позывной, Имя, Город, Район, Страна ... <Еще
> некоторые специфические данные>, дале поля Диапазон и Модуляция


Таблица "Страны" -> таблица "Регионы" -> таблица "Районы"-> таблица "Города".
Связаны "один ко многим".

Таблица "Радиолюбители" (
 ID,
 CityID,
 Codename,
 <Еще некоторые специфические данные>
 Диапазон и Модуляция (вполне возможно, что тоже ссылки на справочные таблицы)
)

> Таблица стран, таблица районов, таблица городов, то есть
> 3 таблицы, а не одна.


Да совершенно верно! Я так и предполагаю. Для каждого варианта запроса (т.к. они могут быть ну очень разные) создавать свою таблицу. Т.е. у меня будет грубо говоря award.mdb, содержащий таблицы для каждого варианта запроса или как вариант таблица одна, но ввести поле указывающее к какому запросу относится эти данные. Здесь понятно.

Теперь к конкретике. Я хочу получить статистику по сработанным районам США и Канады. Создаю таблицу с полями Страна, город, район. Вношу в таблицу данные. Ок!
Теперь нужно получить из таблицы связей и этой таблицы итоговую таблицу статистики с полями Страна, Город, Район, Диапазон1..ДиапазонN. В ячейках Диапазон указывается количество связей/количество отправленных запросов на подтверждение/количество полученных подтверждений.
Вопрос: как правильно сформировать запрос?

> Вопрос: как правильно сформировать запрос?


Тебе сначала нужно нормализовать базу.

> Для каждого варианта запроса (т.к. они могут быть ну очень
> разные) создавать свою таблицу.

Ты сам понял что сказал??? Это как??? Таблицы данных создаются один раз потом этими самыми данными заполняются. После этого строишь любые (какие в голову взбредёт запросы) и получаешь результат. НО для этого сначала (с самого начала) вообще забыть о программировании и идти читать о БД (вообще, а не о конкретной СУБД), потом курить SQL (знакомые буквы?). И только после этого пытаться работать с базами. Иначе получится нечто геммороидальное вроде упомянутого КЛАДРа.

> Alex_C   (01.11.11 10:02) [23]

Не парься. Загрузи свою мегатаблицу в Эксель, тыкни в "Автофильтр" и наслаждайся результатом.

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

> потом курить SQL


Именно этим сейчас и занимаюсь: Введение в SQL Грабер Мартин.


> А местные гуру тебе ничем не помогут


Зра ты так! Очень даже помогают!

>  Введение в SQL Грабер Мартин.


Хорошая, годная книга.


> Зра ты так! Очень даже помогают!


Don't feed the trolls.

Сейчас для начала разбирательства с SQL сдела пробную программу. Взял с готовой программы базы.
Возник такой вопрос: как между собой связать таблицы, если они находятся в разных MDB файлах?

Директива IN. Сам нашел :)

> Возник такой вопрос: как между собой связать таблицы, если
> они находятся в разных MDB файлах?


Зачем такое извращение???

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

> почему извращение? само по себе вещь полезная


Само по себе - возможно.
Но, насколько я понял, автор отнюдь не архивирование имел ввиду...  :)

> Зачем такое извращение???


Опять же из-за специфики программы: сама база (она максимум тыс 150 записей) должна храниться допустим на флешке. Пользователь установил программу на ноуте, дома на компе. Базу переносит на флешке и работает с ней из разных мест. Это обязательное условие для программы.

> Опять же из-за специфики программы: сама база (она максимум
> тыс 150 записей) должна храниться допустим на флешке. Пользователь
> установил программу на ноуте, дома на компе. Базу переносит
> на флешке и работает с ней из разных мест. Это обязательное
> условие для программы.
>


Это всё понятно. Нахрена каждую таблицу держать в отдельном mdb?

> Базу переносит на флешке и работает с ней из разных мест.
ну подключайся прямо к ней, зачем посредники?

или не умеешь работать/менять настройки в рантайме, всегда подключаешься в "дизайне", и думаешь что так и надо?

> Зачем такое извращение???
ты был прав.

> Нахрена каждую таблицу держать в отдельном mdb?
скажем так, по другому.
1 у тебя есть таблицы такого размера, что не помещаются в 1 mdb?
2 у тебя есть запросы объединения, данных с например справочниками, лежащих в разных базах?
3 и последнее. 2 пункт, если такое есть, оно логически оправдано?

В корне неверный подход к хранению данных!!!
Поверь моему опыту, при таком таскании наступит "светлый" момент, когда ты поймёшь, что изменял данные на одном компе, а на флешку забыл базу сбросить, а потом менял данные на другом компе. В итоге у тебя будет таки две, а то и три базы с разными данными и придётся как то их объединять. Или откажись от таскания всей базы (зачем оно вообще нужно???) или предусмотри способ сливания двух баз в одну.
Базу лучше никогда не таскать в рабочем режиме, только при первой установке, а потом переносить только изменения. В идеале база вообще должна быть одна и в одном месте. Организуй хранилище и используй клиент-серверную технологию, так будет правильнее.

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


> Поверь моему опыту, при таком таскании наступит "светлый"
> момент


...и он постоянно наступает. :) Для этого в базе у меня предусмотрено не просто копирование таблиц, а именно слияние.


> зачем оно вообще нужно???


Радиоэкспедиция.


> предусмотри способ сливания двух баз в одну.


Это конечно есть. Я писал выше.


> Нахрена каждую таблицу держать в отдельном mdb?


Приехал с радиоэкспедиции - привез свою базу. Нужно слить все данные в "основную" базу на компе дома.


> Организуй хранилище и используй клиент-серверную технологию


Ридоэкпедиции делаются в такие районы, что не то что интернета, даже электричества не бывает :) Какая тут "технология".

А в итоге я разобрался. SQL - как везде написано, очень простой язык запросов. Проблема немного понять его идеологию. Ниже приведу пример, который думаю поможет начинающим в написании сложных запросов.
Специально для себя все по полочам разложит - по моему так более понятно.
Прошу сильно не пиннать :) А замечания приветствуются!




Небольшие пояснения.
LogTable - имя как раз основной базы, где хранятся связи.
[awards.mdb].Diplom - таблица, где хранятся данные по статистике, которую мы хотим получить.
На сейчас остался один момент - [awards.mdb] - это если база хранится в папке программы. А как прописать полный путь к файлу? По разному пробовал - выдает ошибку.

> А замечания приветствуются!
1 комментарии бессмысленны... описывать что вот здесь а присваивается б... и при этом не написать я для чего это вообще... т.е. цель процедуры. да лучше бы их просто не было.
2 запрос "единым" форматированным куском лучше смотрится и понятнее.
3 ADOQueryLog, до сих пор? я с тобой больше не разговариваю.

> > Нахрена каждую таблицу держать в отдельном mdb?
>
>
> Приехал с радиоэкспедиции - привез свою базу. Нужно слить
> все данные в "основную" базу на компе дома.


Ты, походу, либо путаешься в терминах "таблица БД" и "БД", либо у тебя канонiчный вариант полностью денормализованной базы, состоящей из одной единственной таблицы.

> ADOQueryLog, до сих пор?


Учитывая что я всего 5 дней занимаюсь переделыванием своей программы с VolgaTable на ADO+Access мне простительно.
Во-вторых для начала хотел разобраться в тонкостях написания SQL-запосов.
Теперь пришло время разбираться в тонкостях использования ADO+Delphi.
Пока в этом направлении не понял, почему многие против ADOQuery, но за ADOCommand.

По поводу первых двух пунктов - это я для себя, для полного понимания так сказать! :)


> либо путаешься в терминах "таблица БД" и "БД"


Возможно. БД - это я называю файл .MDB. Таблица - это то, что в файле.

> Alex_C  (02.11.2011 13:38:42)  [42]

Ну тогда не поздно заменить Акцесс на MS SQL

> Возможно. БД - это я называю файл .MDB. Таблица - это то,
>  что в файле.


Ну тогда, похоже, имеем самый жуткий вариант: полностью денормализованную базу.
Геморрой тебе обеспечен. Сочувствую.

> Ну тогда не поздно заменить Акцесс на MS SQL


Вообще не поздно что-то другое выбрать. В данном случае я только в начале переделки.

Когда выбирал БД исходил из следующих пунктов:
1. Один EXE-файл.
2. Нет необходимости устанавливать драйвера БД.
3. Официально бесплатная.
4. Скорость выборки (вот именно то что я и делал выше).
5. Максимальное количество записей в таблице не более 300 тыс.

Я выбирал из Access, FireBird, SQLite. Почитав отзывы остановился на Access.
MS SQL как я знаю требует отдельной установки и хоть минимальной настройки. Т.к. многие из пользователей моей программы компьютерами очень плохо владеют, то это было для меня не совсем удобно.


> полностью денормализованную базу.


Пока еще ничего толком не имеем :)
Сейчас после понятия общих принципов SQL приступаю к нормализации БД, что мне советовали выше.

> ADOQueryLog, до сих пор?


Заметил на ADODataset.
В моем распоряжении сейчас только маленькая БД - всего 10000 тыс записей. Разницы конечно не чувствуется. А на сколько она вообще ощутима на более больших БД?

> Во-вторых для начала хотел разобраться в тонкостях написания SQL-запосов.
> Теперь пришло время разбираться в тонкостях использования ADO+Delphi.


Начни с теории РСУБД и нормализуй базу. Серьёзно. Иначе хлебнёшь проблем по самые гланды.

> маленькая БД - всего 10000 тыс записей.
разные понятия. количество... а вот если 1 запись, но у нее 1000000 тыс полей? (невозможно, но смысл)
это очень маленькая? одно поле всего то...

> А на сколько она вообще ощутима на более больших БД?
количество записей практически не имеет значения. при нормальной структуре/индексах, грамотной работе с ней (выборка только нужного/объединения только по индексированным полям ну и т.д. по месту).
а вот что имеет так это размер базы. проблемы начинались с 1.8 гб.  при официальном ограничении в 2 гб.

> при официальном ограничении в 2 гб.


Это для MSDE 2000, позже, вроде как, увеличили. До скольки Гб - не помню.

> [49] Ega23 ©   (02.11.11 14:37)
> > при официальном ограничении в 2 гб.
>
> Это для MSDE 2000, позже, вроде как, увеличили. До скольки Гб - не помню.

Это про jet видимо было сказано.

> Это про jet видимо было сказано.


Про MSSQL

> Это для MSDE 2000, позже, вроде как, увеличили.
MSDE осталось, это уже новые версии 2008(?) оно уже как то по другому называется, экспресс что-ли... до 4х, а после даже до 10ти гиг. вроде так, да.

> Про MSSQL
вообще то именно про Jet.

> вообще то именно про Jet.
в смысле, в [48] говорил про Jet.

> в смысле, в [48] говорил про Jet.


А, ну может быть, я в Access ни бум-бум.

> Начни с теории РСУБД и нормализуй базу. Серьёзно. Иначе
> хлебнёшь проблем по самые гланды.


Здесь дух мнений быть не может. Абсолютно прав. На выходных буду прорабатывать структуру. Кто бы спорил, я ж не буду (С) Пословица.

Прошу прощения может за глупые вопросы, просто навалилось как бы много всего нового и SQL, и ADO. Вот пока по этому и несколько бестолковые вопросы.


> разные понятия. количество... а вот если 1 запись, но у
> нее 1000000 тыс полей?


Тут несколько другое. У меня есть конкретная база. Да я конечно читал замечательную статью в инете про выбор базы. Выбрать идеальную базу - не возможно. Каждая лучше для конкретного случая.
У меня получается так: реально количество записей от 10 до 300 тыс максимум. Количество полей - до 100 и то это ну на очень будущее. Вот из этого и исхожу.

> Количество полей - до 100 и то это ну на очень будущее.
> Вот из этого и исхожу.


Это крайне плохой признак. В 99% случаев ненормализованная база.
На своей практике встречал 40 полей в таблице, но это было один единственный раз.

> Это крайне плохой признак.


Извини не знаю как тебя зовут, но знаешь.... уже очень долго думал над этим. Тут ОЧЕНЬ большая палка о двух концах. Поверь. Все уж очень специфично.
Ок! Приведу пример: Сначала надо было в базе сохранять минимум сведений: позывной, дата/время, частота, диапазон, модуляция, имя, город, рапорт о приеме. Все. Время идет. Добавляются новые поля. Чисто информативные в своем роде. Не боле того. Например наименование острова с которого работал и т.п. Причем самое главное: вот допустим по островам - ну очень мало кому нужна статистика. Но есть кому нужна. Вот и получается: смысла по этому полю что то думать - нет - и так все в секунду считается.

Опять же: может я не прав. Все еще думаю с позиции ТТабле :)

> Например наименование острова с которого работал и т.п.


Ну вот и создаёшь в базе таблицу "Острова".
create table Islans(ID int, Name varchar(255));
А в "рабочей" таблице добавляешь ссылку на эти самые острова. Т.е. Island_ID.
По-умолчанию - null.

> Ну вот и создаёшь в базе таблицу "Острова".
> create table Islans(ID int, Name varchar(255));
> А в "рабочей" таблице добавляешь ссылку на эти самые острова.
>  Т.е. Island_ID.
> По-умолчанию - null.


Не катит. Боле того - в основной базе такая таблица по островам есть.
Теперь очень распространенное положение - чувак едет на новый остров. Да забыл сказать - многое в базе "информации" появляется после, а не до того, как оно попало в основную базу.

Да забыл сказать - по остовам есть отдельный столбец. Там для каждого диплома выбираются ОТДЕЛЬНЫЕ коды островов.

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

Я понимаю что может для стороннего человека это не понятно... Прошу прощения!

> [57] Alex_C   (02.11.11 17:12)
> позывной, дата/время, частота, диапазон, модуляция, имя,
> город, рапорт о приеме

По крайней мере справочники диапазонов, модуляций, городов уже можно выделить в отдельные таблицы. Далее зачем позывной и имя в каждой записи - тоже в отдельну таблицу вынести - таблица Операторы поля: позывной - уникальный ключ, имя. Кстати, если позывных может быть несколько у одного оператора, то соответсвенно позывные тоже в отдельную таблицу, тогда в Операторы добавляем ID - уникальный ключ, а в таблице Позывные позывной, ID_операторы. Допустим позывной может изменился, старый теперь недействителен - добавляем предусматриваем в Позывные ещё и Дата_присвоения.

Ну и т.п. см.

> [58] Ega23 ©   (02.11.11 17:15)

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


Ну и добавь туда GUID, какие проблемы-то?

> таблица Операторы поля: позывной - уникальный ключ, имя.


Не надо. ID - первичный ключ, "позывной" - уникальный индекс (и то, если нужно. Вполне возможно, что, например, уникальность достигается сочетанием "позывной - частота").

> Я понимаю что может для стороннего человека это не понятно...


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

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

Ну и напоследок:
sniknik ©   (01.11.11 08:32) [16]
при нормально сформированных справочниках сделать конвертацию можно во что угодно, а вот наоборот, из кривого в нормальное часто нереально.

> [62] Ega23 ©   (02.11.11 19:04)
> Вполне возможно, что, например, уникальность достигается
> сочетанием "позывной - частота").

Позывной уникален, но я тоже предпочёл бы сурогатный ID, хоть он и лишний.

> [64] Inovet ©   (02.11.11 19:14)
> Позывной уникален,

И должна быть в природе база позывных. Можно с ней синхронизировать свою.

> Позывной уникален, но я тоже предпочёл бы сурогатный ID,
>  хоть он и лишний.


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

> Тут несколько другое. У меня есть конкретная база. Да я конечно читал замечательную статью в инете про выбор базы.
что значит другое? тебе ясно и конкретно сказали - количество записей в таблице роли не играет, вернее не ту, что ты вкладываешь. откуда вдруг всплыло про выбор базы?

не-адекват какой то.

еще раз - две базы, в них по таблице, в обоих по 100 тыс записей, одна "летает" другая еле ворочается... догадайся какая.
это не значащая информация.
а вот значащая (с сумме), в одной сорок полей, все целочисленные, есть ключ + пара индексов, вся база в сумме несколько мегабайт...
во второй 2 поля типа блоб, индексов нет, вообще ничего нет, не лезет, т.к. все это дело под 2 гб "тянет".
с какой проблемы?

p.s. как в анекдоте...
- Вова ты пойдешь в кино?  
- спасибо мама я уже пообедал!

> [62] Ega23 ©   (02.11.11 19:04)
> позывной - уникальный ключ, имя.

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

> [66] Ega23 ©   (02.11.11 19:18)
> Если позывной - число, то наверное (специфику надо смотреть)да.
> Если строка - то, скорее всего, нет.

Строка. Типичный вид UA1FA, UW3DX, UZ0AWX, RW6ASE, но встречаются и сожнее длиннее. Так что строка.

> Ega23  (02.11.2011 14:54:51)  [51]

msde - 4 gb
MS sQl Server Express R2 - 10 gb

> Inovet  (02.11.2011 19:14:04)  [64]

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

Можешь поверить, я RR2RR

> [71] Anatoly Podgoretsky ©   (02.11.11 19:51)
> Там нет ничего уникального, кроме номера связи

Ты прямо открытие какое-то говоришь. Позывной закрепляется за человеком или радиостанцией, либо я чего не понимаю. Может потом его могут передать другому в случае непродления?

> Inovet ©
> Позывной уникален, но я тоже предпочёл бы сурогатный ID,
>  хоть он и лишний.

Чувак и до первой нормальной формы никак не доберётся, а ты его с пути сбиваешь!!! Твой подход никогда не доведёт до третьей формы, а без неё работать с базой - грубое дилетантство, я бы даже сказал самовредительство и мазохизм.

> Твой подход никогда не доведёт до третьей формы, а без неё
> работать с базой - грубое дилетантство, я бы даже сказал
> самовредительство и мазохизм.


Осознанную разумную денормализацию ещё никто не отменял...  :)

> Осознанную разумную денормализацию ещё никто не отменял.
> ..  :)

Ну вот ты же сам понимаешь, что Денормализация может быть только ПОСЛЕ нормализации. А разумная, только после четвёртой формы, это я как фанат 10й формы говорю. Но ты человек знающий, и так в курсе. Зачем же новичка путать?

> Inovet  (02.11.2011 19:57:13)  [73]

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

Даже больше скажу. Разумная - только после приведения к четвёртой форме. Осознанная, после глубокого анализа выбранной СУБД.
Чувак же выбрал примитивный ACCESS, следовательно, ни о разумности, ни тем более об осознанности речи не идёт.

>  Разумная - только после приведения к четвёртой форме.


Это с какого такого перепуга?


> Чувак же выбрал примитивный ACCESS, следовательно, ни о
> разумности, ни тем более об осознанности речи не идёт.


Эта... А в чём заключается "примитивность" Access с точки зрения теории РСУБД?

> [77] Anatoly Podgoretsky ©   (02.11.11 23:23)
> > Inovet  (02.11.2011 19:57:13)  [73]
>
> Но в логе чужие позывные, и с каждым может быть любое количество связей

Так лог - это уже, так сказать, рабочая таблица, а справочник позывных - другая. Или о чём ты? Ты сказал, что позывной не уникален. Т.е. сегодня ты провёл связь с неким UA1ABC, а завтра под ним кто-то другой уже работает. Я так тебя понял. Возможные случаи, когда у одного человека разные позывные - допустим, при повышении квалификации, при гнографическом перемещении, допустим, может одновременно несколько быть стационарный и какой-нибудь мобильный. И наоборот на одном позывном разные люди - на коллективных станциях, ещё в каких спец случаях.

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

> Эта... А в чём заключается "примитивность" Access с точки
> зрения теории РСУБД?

Примитивность в данном случае понимается как примитивность использования, а не возможностей. Почему именно ACCESS, если его возможности вообще никак не используются? Для этой задачи, если он выбирает ACCESS, ему Delphi совершенно не нужно, всё можно сделать в нём. Как было правильно замечено, тут даже EXCELя за глаза хватило бы.
Отсюда следует вывод, что выбор СУБД не был ничем обоснован. Просто схватил первое, что под руку попалось, даже на каплю не изучив предоставляемые возможности, удобство использования и накладываемые ограничения. Вот как его суперпрограмма будет работать на компе, где нет офиса, а вместе с ним и дровишек?

> [81] Труп Васи Доброго ©   (03.11.11 08:02)
> Вот как его суперпрограмма будет работать на компе, где
> нет офиса, а вместе с ним и дровишек?

Jet есть везде почти.

Пришел утром на работу. Сижу читаю. Приятно, что нас радиолюбителей все же помнят и знают :)
Чуствую что Inovet свой человек - позывные то привел не случайные :)

Теперь конкретно по базе: естественно есть справочники по модуляциям, диапазонам, ... в общем по всему, что только можно. Но есть большое но! Вот эти справочники у каждого человека свои. Т.е. один работает на КВ диапазонах, другой только на УКВ. Каждый для простоты оставляет в справочнике (чтоб потом ему проще было выбирать) только свои диапазоны. И это логично. Пользователю в конечном итоге наплевать на внутренности, ему главное удобство пользования.
По этому что получается: основная база-лог - вот она как есть, так она и есть. Сама по себе. И поверьте мне - уж дума передумал. Никуда ее не нормализуешь.

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

> По этому что получается: основная база-лог - вот она как
> есть, так она и есть. Сама по себе. И поверьте мне - уж
> дума передумал. Никуда ее не нормализуешь.


http://www.gunsmoker.ru/2008/10/x-y-z.html
Засим откланиваюсь.

> [83] Alex_C   (03.11.11 09:04)
> Приятно, что нас радиолюбителей все же помнят и знают :)
>
> Чуствую что Inovet свой человек - позывные то привел не
> случайные :)

Есть здесь на форуме и более опытные, а я немного увлекался в юности.:)

> [83] Alex_C   (03.11.11 09:04)
> Вот эти справочники у каждого человека свои.

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

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

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

> Alex_C  (02.11.2011 17:12:57)  [57]

Два поля лишних - частота и город, первое по сути продублировано диапазоном,
а город не особенно нужен, в основном все рано поле будет пустым, заро не
хватает поля QSL

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


Я конечно понимаю, что профи в программировании БД меня сейчас заклюют, но НЕЛЬЗЯ в данном случае так делать. Почему? Потому что из за специфики хобби НЕТ ПОСТОЯННЫХ справочников.
Привожу пример: человек работает только на УКВ. В справочниках он себе оставил только УКВ диапазоны. Но вот его пригласили поработать радиоэкспедиции. Он там работал на КВ. Приехал - хочет внести свои связи в лог чтобы отписать карточки. А в справочнике нет КВ диапазонов. Запретить ему это делать? Нет конечно. Причем данный пример скорее правило, чем исключение.


> http://www.gunsmoker.ru/2008/10/x-y-z.html
> Засим откланиваюсь.


Повторю ну очень понкретный вопрос :)
[awards.mdb] - это если база хранится в папке программы. А как прописать полный путь к файлу? По разному пробовал - выдает ошибку.

>  но НЕЛЬЗЯ в данном случае так делать.


Давай поспорим, что можно? Что проблема данная решается, легко и непринуждённо?


> [awards.mdb] - это если база хранится в папке программы.
>  А как прописать полный путь к файлу?


Я не понял вопрос.

> Два поля лишних - частота и город, первое по сути продублировано
> диапазоном,


100% с Вами согласен. Но:
1. Многие заносят в лог город того с кем сработал.
2. На счет диапазона и частоты - по началу была только частота - естественно из нее можно получить "диапазон" - текстовое "название" частоты. Ввел диапазон вот по какой причине: при выводе отчета по "диапазону" для каждой связи приходилось пересчитывать частоту в диапазон. При использовании не SQL. Сейчас конечно в этом необходимости нет - при выборке можно указывать BETWEEN для частоты.

> Давай поспорим, что можно? Что проблема данная решается,
>  легко и непринуждённо?


Давай :) Более того: если ты победишь, я буду тебе ОЧЕНЬ признателен. Без каких то шуток. Я пока не могу понять - ну как же это можно реализовать, если справочники не постоянны?


> Я не понял вопрос.


У меня справочники находятся в отдельном MDB файле. Вернее я предполагаю так сделать. Хотя если честно сейчас уже не уверен что это правильно :)
Та вот: мне при JOIN нужно к ним обращаться. (в примере где я процедуру описал.) Так вот : я к ним обращаюсь как [имя файла].имя_таблицы. Но у меня не получается прописать полный путь "имя файла".

> [87] Alex_C   (03.11.11 10:30)
> А в справочнике нет КВ диапазонов.


> [85] Inovet ©   (03.11.11 09:48)
> В интерфейсе заполнение справочников можно сделать достаточно
> удобным - прямо во время заполнения лога, ну и отдельно,
> конечно, тоже.

Справочник заполняет сам пользователь, а не берёт кде-то там унифицированный, хотя второе было бы предпочтительней. Да и полный справочник есть не просит, лежит себе в таблице и лежит, только подставляй значения.

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

В общем всё стандартно.

> [90] Alex_C   (03.11.11 10:41)
> У меня справочники находятся в отдельном MDB файле. Вернее
> я предполагаю так сделать. Хотя если честно сейчас уже не
> уверен что это правильно :)

Это неправильно, за исключением каких-то специфических случаев, к которым данная задача не относится.

> [91] Inovet ©   (03.11.11 10:44)
> Наверное, нет понимания, как это реализовать удобно в интерфейсе?

Ну и да. Лог отображать в гриде с расшифрофками кодов или без, все поля или сокращённый набор - можно это в настройки вынести, чтобы пользователь сделал как ему удобно. При редактировании/добавлении записи открывать другую форму - модальный диалог, на которой уже всё в деталях раписано и всё что надо можно отредактировать, выбрать из справочников. Это можно и в гриде сделать, но лучше не надо.

> Давай :) Более того: если ты победишь, я буду тебе ОЧЕНЬ
> признателен. Без каких то шуток.


ТЗ в студию. Будет подробное нормальное ТЗ - за выходные накидаю макет БД.

Заодно будет повод с Access поиграться... :)

> Alex_C  (03.11.2011 10:36:29)  [89]

Надо поле Примечание, куда можно заносить любую не нужную информацию.

Частоту не так легко пересчитать.
3.500, 3.600, 3.800
Нужен ИИ или вхождение в диапазон

> Inovet ©   (03.11.11 10:44) [91]

Справочник хорошо, когда множество ссылок на одну запись, но в данном случае как правило будет всего одна ссылка на одну запись. Не нужна трата ресурсов, усложнение запросов и многое другое
А справочники диапазонов воовсе смешно. 3.5 в текстовом виде три байта, а со справочником id+значение, минимум 7 байт и необходимость делать JOIN
Вместо справочника лучше строить combobox или pickup list
Почему бы не сделать справочник дат и времени тогда, чем они то хуже?

> [97] Anatoly Podgoretsky ©   (03.11.11 11:43)
> А справочники диапазонов воовсе смешно. 3.5 в текстовом
> виде три байта, а со справочником id+значение, минимум 7
> байт и необходимость делать JOIN
> Вместо справочника лучше строить combobox или pickup list

Одно другого не исключает. Новых диапазонов не предвидится кроме пары десятков уже имеющихся, всместо сурогатного ID пользоваться натуральным ключом. Кому мешает справочник.

Про лог надо ТЗ - Нужно ли там фиксировать повторные сеансы связи с одним и тем же респондентом. Вроде все должны фиксироваться. Тогда справочник, а интерфейсно сделать так же неотличимым от прямого указания позывновго, + будут бонусы в виде уже оговаривавшихся, хотя может бонусы и нафиг не нужны. И сдаётся мне, что должна где-то быть база позывных не только на бумажных носителях.

Отметку об отправленном полученном QSL в логе на каждый сеанс или в справочнике с позывними или там и там.

> Inovet  (03.11.2011 12:07:38)  [98]

По правилам, все связи должны фиксироваться в обязательном порядке
QSL это подтверждение связи, поэтому она должна быть полем, при том поля
два - об отправке и об получение. Справочник здесь вовсе не у дел.

> [99] Anatoly Podgoretsky ©   (03.11.11 12:21)
> По правилам, все связи должны фиксироваться в обязательном
> порядке

Значит в логе.

> А справочники диапазонов воовсе смешно. 3.5 в текстовом
> виде три байта, а со справочником id+значение, минимум 7
> байт и необходимость делать JOIN
> Вместо справочника лучше строить combobox или pickup list


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

> Почему бы не сделать справочник дат и времени тогда, чем
> они то хуже?



> Надо поле Примечание, куда можно заносить любую не нужную
> информацию.


Да, конечно, такое поле в программе есть.


> Частоту не так легко пересчитать.
> 3.500, 3.600, 3.800
> Нужен ИИ или вхождение в диапазон


Есть справочник: такой
3,5    3,5-3,9  80М
Первое поле - значение частоты поля по умолчанию (частота может вручную, а может с трансивера считываться).
Второе - понятно диапазон вхождения.
Третье - текстовое название диапазона.

> [101] Alex_C   (03.11.11 20:58)
> Есть справочник: такой
> 3,5    3,5-3,9  80М

Ну так есть же. Только диапазон частот зачем было в одно поле пихать, тогда уж Low_Frequency, High_Frequency тип с плавающей точкой. Частота с трансивера считалась/ввелась вручную, в справочнике нашли вхождение, заполнили автоматически диапазон. Если без частоты, то вручную заполнили диапазон. Раз он нужен в логе, хоть частоты в принципе достаточно. Код диапазона он же ID может быть например 80 integer.

Как далеко вы от предметной области.
По правилам надо указывать 3.5, а не 3.7 и не 3.715 или 80 м, хотя никто не убьет.

И да это не число, а название

> зачем делать ссылки в данном случае?
в данном может и не зачем (выше приводили пример когда сама ссылка больше чем значение, и встречается только в 1 таблице)

а вообще, делаются по многим причинам, например:
тот же размер. если например страна "Союз Советских Социалистических Республик" то гораздо выгоднее хранить ее в одном месте, а в таблицу класть ее ID(ссылку). и работает так часто быстрее (не записываются объемные данные, не нужно перестраивать по ним индексов...)
или удобство изменений, ну к примеру ввели страну - Татарстан, делают записи с ней, а потом вдруг, внезапно - "в написание вкралась ошибка! надо писать не Татарстан, а Грузия2...". в одном случае просто меняешь название в справочнике, в другом ищешь все места где используешь и запросами меняешь значение... еще и следишь чтобы с реальной Грузией не попутать.

> [104] Anatoly Podgoretsky ©   (04.11.11 07:46)
> И да это не число, а название

Да я не о том, а об ID и внешенм ключе на него из лога. Пусть будет 3500 или 3,5 с фиксированной точкой. Главное - проверка на уровне базы а не приложения и связь со справночником при необходимости. Врямя года или там пол "М" "Ж" устоявшиеся понятия, а диапазонов много и завтра поменяют/добавят/уберут.

Тоже и с модуляцией.

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

> [69] Inovet ©   (02.11.11 19:23)
> UW3DX

UW3DI

> Inovet  (04.11.2011 10:56:46)  [106]

Не требуется, все одно или CW или SSB и редко экзотика вроде FAX

> По правилам надо указывать 3.5, а не 3.7 и не 3.715 или
> 80 м, хотя никто не убьет.


По диапазонам правил как таковых нет, есть общепризнанный межлоговоый формат ADIF, в нем указывается название диапазона 80M, 40M, 20M. И менно по тому полю считают дипломы. А поле частота 3,5 или 3,8 или 3,550 - это уже как хочешь указываешь. Однако естественно название высчитывается из частоты.


> Не требуется, все одно или CW или SSB и редко экзотика вроде
> FAX


Сейчас все немного сложнее: CW, SSB - да, так и осталось, но есть много новых цифровых видов связи. К уже существующей RTTY добавились PSK, ROS, SSTV. Так вот: в некоторых дипломах все цифровые виды связи считаются как один и тот же, в некоторых - как разные.
Но это уже техника!

Спасибо большое за активное обсуждение темы. Сейчас есть много поводов подумать над архитектурой БД.

Офтоп:
UW3DI - первый трансивер который я сделал сам :)

> [14] Труп Васи Доброго ©   (01.11.11 08:21)
> Не поминай это овно, КЛАДР наверное ключница делала. Может
> сейчас что то исправили, давно с ним не работал, но то,
> что я видел лет 5 назад это ППЦ. Создатель либо полный профан,
> причём с дикого бодуна писал и слово нормализация для него
> просто звук, либо с.ка вредитель.

Кладр нормализуется из заготовки, хоть и коряво - что делать, если почтовые адреса ненормализованны. Только он не очнь годится для данной задачи.

> [110] Inovet ©   (04.11.11 13:26)
> Только он не очнь годится для данной задачи.

Но привязать можно только как раз здесь хранить не ID и сами названия.
Сам КЛАДР вот, он периодически обновляется
http://www.gnivc.ru/inf_provision/classifiers_reference/kladr

> [111] Inovet ©   (04.11.11 13:31)
> http://www.gnivc.ru/inf_provision/classifiers_reference/kladr

Вот так надо
http://www.gnivc.ru/inf_provision/classifiers_reference/kladr/

тип продукта  - выводятся:наименование  продукта,сот,цена,тип продукта,количество в наличии,год производства.Запрос на выборку с помощью SQL как это сделать???

тип продукта  - выводятся:наименование  продукта,сот,цена,тип продукта,количество в наличии,год производства.Запрос на выборку с помощью SQL как это сделать???

тип продукта  - выводятся:наименование  продукта,сот,цена,тип продукта,количество в наличии,год производства.Запрос на выборку с помощью SQL как это сделать???

тип продукта  - выводятся:наименование  продукта,сот,цена,тип продукта,количество в наличии,год производства.Запрос на выборку с помощью SQL как это сделать???

> асема   (19.02.12 01:27) [113]
>
> тип продукта  - выводятся:наименование  продукта,сот,цена,
> тип продукта,количество в наличии,год производства.Запрос
> на выборку с помощью SQL как это сделать???

"Нанять программиста".
(c) Плохиш

> асема   (19.02.12 01:27) [113]
>
> тип продукта  - выводятся:наименование  продукта,сот,цена,
> тип продукта,количество в наличии,год производства.Запрос
> на выборку с помощью SQL как это сделать???

"Нанять программиста".
(c) Плохиш

> асема   (19.02.12 01:27) [113]
>
> тип продукта  - выводятся:наименование  продукта,сот,цена,
> тип продукта,количество в наличии,год производства.Запрос
> на выборку с помощью SQL как это сделать???

"Нанять программиста".
(c) Плохиш

> асема   (19.02.12 01:27) [113]
>
> тип продукта  - выводятся:наименование  продукта,сот,цена,
> тип продукта,количество в наличии,год производства.Запрос
> на выборку с помощью SQL как это сделать???

"Нанять программиста".
(c) Плохиш