> А замечания приветствуются!
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.


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

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

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

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