ШыфлНа MSSQL при создании внешнего ключа к справочнику по нему автоматом создаётся индексПри создании ограничений типа FOREIGN KEY на MSSQL индекс автоматически не создается. Об этом внятно указано в документации и легко подтвердить простым тестом. Индексы автоматически создаются только на ограничения типа PRIMARY KEY и UNIQUE, о чём также написано в документации.

ШыфлChA,
спорить не буду, но по-моему до 2005 всё создавалось.И не надо. Я работал с MS SQL начиная с версии 4.21 и никогда он автоматически не создавал индексы для FK. Для проверки целостности нет необходимости в индексе на таблице с FK, так как поиск существования значения происходит в другой таблице с PK или UQ ограничением, в которых обязательно есть соответсвующий индекс. Индексе на таблице с FK нужен только, если планируется активное соединение обоих таблиц по ссылочным полям, да и то не всегда, обратите внимание на комментарий p2.

ШыфлВообще заметил странную тенденцию - при создании дополнительных индексов, скорость выборок в линкованных таблицах Access парадоксально падает! Очевидно из-за возрастающей нагрузки на сеть (асс тянет все данные себе, и только потом начинает их обрабатывать, возможно даже без использования индекса как такового). Естественно потом это всё нужно переделать на прямые запросы к серверу, но это очень много работы, а хочется иметь функциональный вариант уже сейчас...Вы думаете postgresql всё сделает за вас ? Если вы плохо знаете инструментарий с которым работаете, то переход на другой сервер не поможет. Возможно, даже усложнит, так в postgresql много не так, как в MS SQL и MS Access, о которых у вас есть хоть какое-то представление.

Шыфлне достаточно знать, как себя ведёт PG, нужно ещё понять, как себя с ним будет вести Access. Выяснилось, к примеру, что DAO.Recordset.FindFirst, который на таблице Jet без индекса отрабатывал моментом, с случае с PG ODBC без индекса просто зависает. А, например, если создать пару-тройку индексов на большой таблице, то они по размеру займут места больше, чем сама таблица и Access при работе с формами начинает подтормаживать :( Ещё хотелось бы знать, как поведёт себя PG c таблицами без первичного ключа при массовой вставке/удалении...Если вы работаете с SQL-сервером любого вида через MS Access, то надо забыть о файлсерверных привычках. Насколько помню, там есть механизм ODBC Direct, который позволяет посылать запросы на выполнение серверу, а не тащить все данные на клиента и выполнять запрос на месте.
Не понял о каких индексах вы хотели сказать, индексы должны быть на сервере и пользоватся его engine. MS Access не должен создавать никаких локальных индексов в таком случае, он должен "тупо" посылать на сервер "правильные" запросы.
За таблицу без первичного ключа надо увольнять за профнепригодность. Никогда не надейтесь ни на какие "встроенные" уникальные идентификаторы. Они живут собственной жизнью и вы можете сильно пострадать, если решите, что их использование - нормальная практика. Всегда только явные и понятные вам primary key.

pihelChA,
Подскажите, в PostgreSQL, как Oracle, если на fk таблицы-факта нет индекса, то при обновлении зависимой справочной таблицы будет наложен share lock на связанную таблицу-факт?
(оракловая дока: http://docs.oracle.com/cd/E11882_01/server.112/e40540/datainte.htm#CNCPT1660 "Prevents a full table lock on the child table. Instead, the database acquires a row lock on the index." )
Или в PostgreSQL этой проблемы нет?Понятия не имею, у меня стаж в PostgreSQL минимален. Этот вопрос лучше не ко мне. Хотя чисто по логике, в этом есть здравый смысл. Данные в обоих таблицах согласованы, значит при обновлении одной требуется верификация значения в другой, и без лока, тут, ну никак не обойтись, точнее, можно, но гораздо более дорогой ценой. Другой вопрос, что без индекса придется сканировать всю таблицу, поэтому проще всего наложить временную разделяемую табличную блокировку. В то же время, обновления полей в pk это плохая практика, так как оно собственно и требует каскадных проверок в подчинёненных(fk) таблицах. Именно поэтому активно используются суррогатные ключи, которые нет нужды менять на протяжениии всего жизненного цикла сущности. А раз pk меняться не будет, то и необходимости в блокировке связанных таблиц не появится, разве только при удалении. Но удаление сущности, в принципе, более сложный вопрос, чем только удаление строки из таблицы. В грамотных системах и удаления, как правило, не происходит, чтобы сохранить целостность исторической картины. Просто каким-либо признаком сущность выводится из активных. Обычно периодом существования или моментом с которого она считается активной, тут есть нюансы.

ШыфлС сервером я обычно работаю через ADO/ADO.net, но тут пришлось столкнуться с суровым DAO.Насколько помню, ADO заточен под MS SQL Server. Всё-таки, если собираетесь продолжать использовать MS Access в качестве frontend, то настоятельно рекомендую разобраться с ODBC Direct.ШыфлКакие запросы посылает на сервер MS Access мне бы тоже очень хотелось знать. Не подскажете нормальный бесплатный трассировщик запросов для PG? Потому что там хитрая система - он посылает запрос, а пока он грузится, посылает второй запрос вдогонку для отображения на форме части полученных данных. Надо бы посмотреть, как это работает "поближе". К тому же, когда у вас таблица на 100мб и 150мб индексов к ней, это ИМХО не здорОво, хотя бы с точки зрения нагрузки на shared_buffers...Именно поэтому пользуйтесь прямым доступом(ODBC Direct), а не через DAO. Это не так уж сложно, просто в запросах MS Access подправить нужные свойства. Тогда всё будет очевидно, что послали, то и "полетело". И никаких индексов на стороне MS Access. А по поводу трассировщика, такого как под MS SQL нет, так что кроме гугля ничего рекомендовать не возьмусь. Многие вообще пользуются анализом логов.ШыфлА вообще, за профнепригодность нужно увольнять тех, кто такие таблицы ака "куча" не умеет использовать.Возможно, вы мастер использования "куч", но вы нарушаете базовый принцип РМД, все элементы множества должны быть уникально идентифицируемы. В противном случае, вы рискуете "поскользнуться" на "куче" в любой момент. Впрочем, хозяин - барин.

ШыфлЧто-то мне уже не нравится PG за подобные вольности...

Если в названиях используются кавычки, а внутри них буквы с разными регистрами и на других языках, то потом везде придется писать эти названия в кавычках. Такая особенность, но явно прописанная в документации. Лучше не смешивать стиль написания с кавычками или без кавычек. И лучше забыть о русских наименованиях в принципе.

P.S. Вас же предупреждали, что в postgresql много не так, как в MS SQL или MS Access. Ещё не раз споткнётесь.