Korwin (*) (2003-02-13 12:25:41.012)

Добрый день

Про это тоже думали - может быть воспользуемся. Только у нас не только perl, но и fortran :) А про int8 кто-то уже жаловался, что тоже есть проблемы с индексам: так что int4 и проблема 2032 года :)

Потребовать чтобы всегда пользовалась индексами можно, но как я понял это можно сделать только для всей БД, что не правильно.

С уважением Евгений

To Evgueni...

set enable_seqscan=off

Должно помочь.

И еще: Работа с массивами в целом? Тогда можно попробовать нереляционную особенность сабжа -- массивы. См. документацию.

2 Сергей Маслов

>Пример не самой большой таблиц..

Но, согласитесь, что таблица с количеством полей > 50, это скорее исключение, чем правило, даже в крупных разработках, и в контексте этого треда больше походит на плохой дизайн. Интересно было бы узнать статистику по этому поводу :)))

К стати: ISN - как можно расшифровать?

Alter (*) (2003-02-15 13:24:53.604)

>>Пример не самой большой таблиц..
>Но, согласитесь, что таблица с количеством полей > 50, это скорее исключение, чем правило, даже в крупных разработках, и в контексте этого треда больше походит на плохой дизайн. Интересно было бы узнать статистику по этому поводу :)))

Соглашусь.
Вас интересует статистика по нашей системе? Точных цифр не скажу, да и права не имею, но скажем так, их несколько штук на пару сотен таблиц. Но много широких VIEW.

>К стати: ISN - как можно расшифровать?
Internal System Number. В нашем случае по разным причинах мог присутствовать и External...

P.S. Отвечаю нерегулярно - гриппую :((

С уважением, Сергей Маслов

>А через недельку, приходит к Вам заказчик и говорит: а теперь мне нужен поиск по этому полю

А задавать поиск по одному/нескольким (но не всем) полям многостолбцовйо таблицы религия запрещает?..

Кто-то из нас не все прочитал или чего-то недоговаривает. Дискуссия была
такой:

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

>> А теперь я добавлю копейку в копилку "противников 60 полей" ;-))) На
>> самом деле эти данные нужно разбивать на поля только в том случае,
>> когда по какой-либо их части делается поиск.

> А через недельку, приходит к Вам заказчик и говорит: а теперь мне
> нужен поиск по этому полю

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

Bard

> Вопрос: кто и где собирался искать по всем атрибутам?

И почему ему захотелось этого "потом" ? И куда он смотрел, когда подписывал ТЗ ?... И почему, если мед есть, то его сразу нет ?? ;-))))

> И куда он смотрел, когда подписывал ТЗ ?

Ой, ну про ТЗ и вообще процесс разработки, основанный на подписанном
ТЗ можно много добрых слов говорить... Поскольку речь шла о уже якобы
имеющихся 5 миллионах записей в таблице с такой неприятностью, то, надо
думать, система уже даже сдана в эксплуатацию. Значит, произошло нечто
такое, чего заказчик не учел ни в момент разработки ТЗ, ни даже после.
Ну например, свалился вышеупомянутый приказ из МНС ;). Тут можно
обвинить заказчика, мол, сам дурак, надо было думать, что паспортные
данные резать придется, но, с другой стороны, откуда ему знать, что
в этих ваших компьютерах так тяжело атрибуты разрезать? Он то слышал,
что компьютеры облегчают труд человека, а значит с такой-то плевой
задачей легко справиться должны...

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