Сортировка в TTable

← →
Sirgfine (2004-04-13 05:02) [0]

Задавал я как-то этот вопрос, но ответа так и не получил, а между тем надобность возрастает.
Короче вопрос элементарен: Delphi разрешает сортировать только по имеющимся физически (в базе на винте) полям, а там всего-лишь индексы, да к тому же два (тип и наименование). А надо выдать юзеру отсортированную по текстовому наименованию таблицу. Что делать?
(может я конечно и торможу, но для меня это серьёзная проблема)

← →
ЮЮ © (2004-04-13 05:55) [1]

А если там индексы, это значит, что сушествует как минимум две связанные таблицы, а значит надо переходить к TQuery и в запросе явно связывать обе таблицы и сортировать по полю Name второй таблицы. Да и вываливать пользователю всю таблицу тоже не есть гуд. Поэтому Query позволит и ограничить количество строк (а необходимость в этом тоже будет возрастать, т.к. теперь дополнительно к целому значению поля кода приходится тащить ещё и текстовое поле значения)

← →
Anatoly Podgoretsky © (2004-04-13 08:58) [2]

А с помощью чего сделан доступ к таблицам

← →
sniknik © (2004-04-13 10:48) [3]

Anatoly Podgoretsky © (13.04.04 08:58) [2]
задавали ему этот вопрос, но ответа не получили. ;о) судя по тому, что надобность возрастает а решения как не было так и нет.

← →
Anatoly Podgoretsky © (2004-04-13 10:49) [4]

Ну пока надобность еще не достигла критической отметки. А долго мучили?

← →
sniknik © (2004-04-13 11:01) [5]

да не знаю я, ;) это так догадка. (а почему еще обычно ответов не получают?)

← →
Sirgfine (2004-04-18 01:27) [6]

Извините за молчание. Просто учёба меня к стенке прижала, не смог вовремя оплатить Internet.
Доступ: BDE.
Формат базы данных: DBase
Компонент: TTable

← →
Sirgfine (2004-04-18 01:29) [7]

С SQL работать умею (на примитивном уровне). Сделать желаемое на sql могу, но нет смысла, так как надо достичь максимальной производительности на локальной Pentium 133 машине.
К тому же некрасиво делать 1 отчёт (самый простой на SQL) а остальные (которые сделать на SQL мне не под силу) c помощью дригух методов (простых проходов по таблицам и суммирования информации).

← →
Sirgfine (2004-04-18 01:36) [8]

Проблема бональна: надо ввести индекс на поле, у которого FieldKind =fkLookup. А дельфи при таком подходе говорит, что для такого поля нет индексов, а индексы я могу создать только для полей fkData, т.е. тех, которые у меня физически есть в базе.
А вчера идея проскачила: а может просто сортировать базу (физически) на винте в перерывах в работе (например ночью) и голову не ломать?

← →
Sirgfine (2004-04-18 01:38) [9]

Короче буду благодарен за любой совет
(кроме разглагольствований на тему " а SQL всё-равно круче!")

← →
Term © (2004-04-18 10:24) [10]

> А вчера идея проскачила: а может просто сортировать базу
> (физически) на винте в перерывах в работе (например ночью)
> и голову не ломать?

ты чем по ночам занимаешся что тебя такие мысли посещают???!!!

← →
sniknik © (2004-04-18 10:42) [11]

> кроме разглагольствований на тему " а SQL всё-равно круче!"
не круче, другой принцип, и самое простое решение в твоем случае.

> надо ввести индекс на поле, у которого FieldKind =fkLookup.
переделай таблицу, чтобы это поле было реальным, и с индексом. (дублировать поля в 2 таблицах). и хотя это нарушение нормализации это тоже выход, не такой как с SQL но полутше чем ночью базу физически сортировать.

← →
KSergey © (2004-04-18 11:48) [12]

> и хотя это нарушение нормализации

В принципе, такое решение часто можно видеть в DBF-базах
Так что наверное нет смысла комплексовать из каких-то там... ;)

← →
Viktor (2004-04-18 13:10) [13]

> ЮЮ © (13.04.04 05:55) [1]

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

подскажите пожалуйста как это сделать...

← →
Sirgfine (2004-04-18 13:31) [14]

Введение дополнительных полей это грубейшая ошибка!
При этом конкретно упадёт скорость (они же текстовые), а также будет нарушена логика работы программы (придётся дополнительно выполнять мероприятия по синхронизации).
А физическая сортировка по моим подсчётам (и тестам) будет выполняться не более чем 15 минут, ведь все таблицы сортировать не надо, только источники индексов (список типов, список товаров, список отделов, список клиентов...).

← →
Sirgfine (2004-04-18 13:38) [15]

дискусия похоже смешается в обычном направлении.
Ваши соображения это не решения, это или предложение повернуть на 180 градусов (SQL) или воспользоваться заранее тупиковыми методами(введение дополнительных полей).
Мне надо просто создать индекс!!! Неужели никто не может сказать как это сделать для fkLookup полей? Ведь даже меотд такой есть:
TTable.IndexDefs.Add(...). Он работает!, но при попытке активизировать индекс появляется Exeption, в которой говориться о том, что отсутствуют индексы для этих полей.

← →
sniknik © (2004-04-18 13:49) [16]

Sirgfine (18.04.04 13:31) [14]
> Введение дополнительных полей это грубейшая ошибка!
> При этом конкретно упадёт скорость (они же текстовые), а также будет нарушена логика работы программы (придётся дополнительно
> выполнять мероприятия по синхронизации).
как уже говорилось не надо по этому поводу комплексы культивировать (хватит одного по поводу SQL ;о), тем более ты не прав насчет скорости, если будет индекс по полю то скорость скорее всего возрастет. а вот то что неохота чегото переделывать это да это аргумент... :)

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

p.s. товарищ свою нормализацию до сих пор устраняет (уже ~4 мес)

← →
Sirgfine (2004-04-19 21:53) [17]

Не введение дополнительных полей это не решение. При этом и объём базы значительно увеличиться!
В этом случае лучше уж базу сортировать вручную по какой-нибудь клавише. При этом кстати и SQL CreateTable использовать не зазорно!

А всё-таки, как динамически (во время выполнения) создать индекс по fkLookup полю? (мне это уже просто интересно. Неужели нельзя?)

просто интересно почему некоторые задающие вопрос настолько упрямы???
сказали же SQL самое простое самое лучшее решение в данном варианте. А на счет красиво некрасиво - это какие то корявые рассуждения. Кто-то вам "предъявит" за то, что вы использовали SQL?

> это или предложение повернуть на 180 градусов (SQL) или
> воспользоваться заранее тупиковыми методами(введение дополнительных
> полей).

SQL - это не 180 градусов, а наоброт совершенно верный курс. Используйте SQL и у вас сотни вопрос отпадут сами собой.
Тока опять не пишите, что это не решение. Что смогли то предложили. Дальше своими руками. Включайте мозг! :))))

> создать индекс по fkLookup полю?
а ты можеш участвовать в автогонках без машины? ну так вперед. а индексов без данных не бывает.

> При этом кстати и SQL CreateTable использовать не зазорно!
странные представления зазорно/не зазорно. есть наверное и то что использовать стыдно, или противно?
дружеский совет сходи к психоаналитику попроси избавить тебя от комплексов в программировании. (заменить их на лутше/хуже/рабочее/нерабочее/более подходяшее в данной ситуации)

> Sirgfine

И на ... сесть и рыбку съесть. Так не получится. Есть масса вариантов от "физической сортировки" ( ;-) ) до SQL, выбириай любой.

← →
Sirgfine (2004-04-22 00:53) [21]

>> а ты можеш участвовать в автогонках без машины? ну так вперед. а индексов без данных не бывает.
1) Если есть поле, значит можно и индекс сделать (я уже говорил, что для этого даже методы специальные есть);
2) Использование SQL на при локальной работе понижает скорость (это в любом SDK написано);
3) Вывод из ветки: придётся сортировать "физически"....

> Использование SQL на при локальной работе понижает скорость
>

а до этого у тебя все просто летало??????
не всегда скорость есть главное.... а вот > сортировать "физически".... - бррррр.... :((( это по-моему хуже чем SQL...
лучше попробуй а потом будешь отвергать.. причем все варианты и выбери приемлемый... все познается в сравнении !

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

Сортировка в TTable Найти похожие ветки