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

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

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

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

Симонов Денис,
первое из сообщений о нескольких событиях в 1 день - я не так выразился. именно запись в днях всего одна. просто имел ввиду, что она не зависит от времени. А там где зависимость от времени есть(во сколько пришел сотрудник) - там имеется связь с днем по ключу дата.

Как то отошли сильно от темы.
Крохотная база, записей в ней мало. Например выполняю запрос:
Select * from summa where "ID" = (Select "ID_UTRO" from VIRUCHKA where "DATE" = '24.05.2014')

При выполнении локально(на компьютере с БД):
Plan
PLAN (VIRUCHKA INDEX (RDB$PRIMARY4))
PLAN (SUMMA INDEX (PK_SUMMA))

Adapted Plan
PLAN (VIRUCHKA INDEX (INTEG_24))
PLAN (SUMMA INDEX (PK_SUMMA))

------ Performance info ------
Prepare time = 0ms
Execute time = 0ms
Avg fetch time = 0,00 ms

Из локальной сети выполняется тоже мгновенно.

Через интернет этот запрос выполняется:
Plan
PLAN (VIRUCHKA INDEX (RDB$PRIMARY4))
PLAN (SUMMA INDEX (PK_SUMMA))

Adapted Plan
PLAN (VIRUCHKA INDEX (INTEG_24))
PLAN (SUMMA INDEX (PK_SUMMA))

------ Performance info ------
Prepare time = 3s 167ms
Execute time = 234ms
Avg fetch time = 234,00 ms

То есть 0 мс и 3167 мс - разница в подготовке при запросе из локальной и внешней сети...

ISQL выполняет запрос через интернет за:
ELAPSED TIME= 0,67 sec
что в разы быстрее чем в IBE или моей проге C# .net.
но при этом, на мой взгляд все равно много.

kdv,
ping h.photocopir.ru
Ответ от 109.188.74.142: число байт=32 время=25мс TTL=54

tracert h.photocopir.ru
Трассировка маршрута к h.photocopir.ru [109.188.74.142]
с максимальным числом прыжков 30:

1 <1 мс <1 мс <1 мс 192.168.1.1
2 1 ms 1 ms 1 ms broadband-188-244-38-1.2com.net [188.244.38.1]
3 6 ms 3 ms 1 ms 172.31.244.1
4 7 ms 2 ms 11 ms juni-vl-165-m10.setel.ru [80.253.16.169]
5 4 ms 5 ms 6 ms msk-ix-peer.yota.ru [193.232.246.138]
6 * * * Превышен интервал ожидания для запроса.
7 * * * Превышен интервал ожидания для запроса.
8 * * * Превышен интервал ожидания для запроса.
9 32 ms 30 ms 29 ms client.yota.ru [109.188.74.142]

Трассировка завершена.

За совет про джоин спасибо, но время только выросло от этого...

Select summa.* from summa
inner join VIRUCHKA on "ID_UTRO"=summa.id where "DATE" = '24.05.2014'

Plan
PLAN JOIN (VIRUCHKA INDEX (RDB$PRIMARY4), SUMMA INDEX (PK_SUMMA))

Adapted Plan
PLAN JOIN (VIRUCHKA INDEX (INTEG_24), SUMMA INDEX (PK_SUMMA))

------ Performance info ------
Prepare time = 3s 962ms
Execute time = 296ms

Симонов Денис,
За это биг спс. заменил * перечислением всех полей. время упало почти вдвое:

Prepare time = 2s 294ms
Execute time = 156ms


Dimitry Sibiryakov,
я бы с удовольствием поставил вторую локальную базу, она б и бэкапом была заодно.
Но в связи с тем, что доступ к интернету не стабилен, да и вырубить комп могут, то необходима Двусторонняя асинхронная репликация БД. Как на ФБ организовать такое штатными методами я не нашел, а вручную самому такое реализовывать - это ооочень долго выйдет и того не стоит.

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

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

Gallemar,

К сожалению она тоже платная. а 8 лицензий покупать не вариант.
когда размер баз максимум 3 мб - глупо платить 1000 баксов за автоматическое одностороннее копирование изменений раз в 30 сек - проще уж, всю базу копировать как файл раз в 30 сек, программка из 5 строк выйдет:)