Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Сортировка в TTable [D7, dBase, FoxPro]

Страницы: 1 2 >
Sirgfine © (2004-04-13 05:02:00)
Задавал я как-то этот вопрос, но ответа так и не получил, а между тем надобность возрастает.
Короче вопрос элементарен: Delphi разрешает сортировать только по имеющимся физически (в базе на винте) полям, а там всего-лишь индексы, да к тому же два (тип и наименование). А надо выдать юзеру отсортированную по текстовому наименованию таблицу. Что делать?
(может я конечно и торможу, но для меня это серьёзная проблема)

sniknik (2004-04-22 08:31:00) [1]
> 1) Если есть поле, значит можно и индекс сделать (я уже говорил, что для этого даже методы специальные есть);
я не ошибаюсь ты вроде говорил что это Lookup поле? ну так пусть это будет потрясением но я скажу, сядь только прежде чем дальше читать.
этого поля в этой таблице нет, это ссылка на поле другой таблици вот там ты можеш сделать индекс но только не в этой.
кстати сколько бы ты не повторял желаемое, действительности это не изменит.

Ильш (2004-04-22 06:27:00) [2]

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

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

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

VAleksey (2004-04-20 09:24:00) [4]

> Sirgfine

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

sniknik (2004-04-20 08:10:00) [5]
> создать индекс по fkLookup полю?
а ты можеш участвовать в автогонках без машины? ну так вперед. а индексов без данных не бывает.

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

Ильш (2004-04-20 06:22:00) [6]
просто интересно почему некоторые задающие вопрос настолько упрямы???
сказали же SQL самое простое самое лучшее решение в данном варианте. А на счет красиво некрасиво - это какие то корявые рассуждения. Кто-то вам "предъявит" за то, что вы использовали SQL?

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

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

Sirgfine (2004-04-19 21:53:00) [7]
Не введение дополнительных полей это не решение. При этом и объём базы значительно увеличиться!
В этом случае лучше уж базу сортировать вручную по какой-нибудь клавише. При этом кстати и SQL CreateTable использовать не зазорно!

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

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

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

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

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

Sirgfine (2004-04-18 13:31:00) [10]
Введение дополнительных полей это грубейшая ошибка!
При этом конкретно упадёт скорость (они же текстовые), а также будет нарушена логика работы программы (придётся дополнительно выполнять мероприятия по синхронизации).
А физическая сортировка по моим подсчётам (и тестам) будет выполняться не более чем 15 минут, ведь все таблицы сортировать не надо, только источники индексов (список типов, список товаров, список отделов, список клиентов...).

Viktor (2004-04-18 13:10:00) [11]
> ЮЮ © (13.04.04 05:55) [1]

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

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

KSergey (2004-04-18 11:48:00) [12]
> и хотя это нарушение нормализации

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

sniknik (2004-04-18 10:42:00) [13]
> кроме разглагольствований на тему " а SQL всё-равно круче!"
не круче, другой принцип, и самое простое решение в твоем случае.

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

Term (2004-04-18 10:24:00) [14]

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

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

Sirgfine (2004-04-18 01:38:00) [15]
Короче буду благодарен за любой совет
(кроме разглагольствований на тему " а SQL всё-равно круче!")

Sirgfine (2004-04-18 01:36:00) [16]
Проблема бональна: надо ввести индекс на поле, у которого FieldKind =fkLookup. А дельфи при таком подходе говорит, что для такого поля нет индексов, а индексы я могу создать только для полей fkData, т.е. тех, которые у меня физически есть в базе.
А вчера идея проскачила: а может просто сортировать базу (физически) на винте в перерывах в работе (например ночью) и голову не ломать?

Sirgfine (2004-04-18 01:29:00) [17]
С SQL работать умею (на примитивном уровне). Сделать желаемое на sql могу, но нет смысла, так как надо достичь максимальной производительности на локальной Pentium 133 машине.
К тому же некрасиво делать 1 отчёт (самый простой на SQL) а остальные (которые сделать на SQL мне не под силу) c помощью дригух методов (простых проходов по таблицам и суммирования информации).

Sirgfine (2004-04-18 01:27:00) [18]
Извините за молчание. Просто учёба меня к стенке прижала, не смог вовремя оплатить Internet.
Доступ: BDE.
Формат базы данных: DBase
Компонент: TTable

sniknik (2004-04-13 11:01:00) [19]
да не знаю я, ;) это так догадка. (а почему еще обычно ответов не получают?)

Anatoly Podgoretsky (2004-04-13 10:49:00) [20]
Ну пока надобность еще не достигла критической отметки. А долго мучили?

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »