Ясно, мемо - "хрень", 3 раза по тексту...;)

of63
Ясно, мемо - "хрень", 3 раза по тексту...;)

Офа, не виноватая я, они сами

Да, ладно, я ниче. Полевой вопрос каждый решает сам - какой достался, с тем и ... живешь

Simple777
Такая реализация у меня в проектах есть, и никаких проблем с этим не было ни по скорости, ни ещё по чему-либо.

Всяк кулик своё болото хвалит...
Но это на самом деле г*но-решение в чистом виде. Ничего не поделаешь - любой костыль прикрывающий убожество системы именно таким и будет...

Божья_коровка
Восторг тов. Симпле777 по поводу FPD не разделяю

У меня, в свою очередь, не вызывают восторга труднообъяснимые глюки VFP как на этапе отладки, так и в исполнимых модулях. [attachment 28895 bk.gif]

Igor Korolyov
Ничего не поделаешь - любой костыль прикрывающий убожество системы именно таким и будет...

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

Думаю что в данном вопросе клиент проголосует рублём. В конце концов если уж и сам автор таки предпочитает использовать графические интерфейсы для банального чтения и написания текстов на этом форуме, значит прекрасно понимает ущербность подхода "только консоль 80*25".

of63
...А почему Memo не использовано? Чтобы можно было индексировать по полю C(150) и искать?...
...Или, например, заменить поле C(150) на ID (число), ID указывает на запись вспомогательной таблички {ID, Memo} с наименованием любой длины. Тогда найдем в вспомогательной табличке нужное наименование, его ID, ищем это ID в "основной" табличке...

Речь идет о том, что надо выполнять произвольные выборки из очень длинных наименований. Положим, есть подарочные наборы, где в наименовании (которое может быть очень длинным - не я это придумал) перечисляются продукты, а также их место производства (где родилась корова, чем питалась, сколько прожила, когда именно у нее брали молоко и т.п.) или происхождения. Скажем, есть 100500 таких наборов. Нас интересуют только те наборы, где в наименовании встречается слово "водка" и слово "селедка". Надо отобрать такие записи и вывести для просмотра. Использование двух таблиц для хранения длинных наименований этому не препятствует. И во второй таблице, допустим, будет 5% записей от числа записей с первой таблице. Можно без проблем сделать выборку по AT() и даже проиндексировать по алфавиту, есличо.

Igor Korolyov
Думаю что в данном вопросе клиент проголосует рублём. В конце концов если уж и сам автор таки предпочитает использовать графические интерфейсы для банального чтения и написания текстов на этом форуме, значит прекрасно понимает ущербность подхода "только консоль 80*25".

Это вопрос не ущербности, а целесообразности прежде всего. И да, клиент голосует рублем. Тут согласен. Меня итоги голосования устраивают.

Simple777
Использование двух таблиц для хранения длинных наименований этому не препятствует.

Только если всегда искать по tbl1.fld1+tbl2.fld2 (ну или аналогично если эти куски в полях одной таблицы находятся).
Т.к. обеспечить поиск скажем простейшей фразы "русская водка" если этот текст оказался на "линии разреза" иным образом практически невозможно. Ты не можешь даже гарантировать что одиночное "слово" не будет разрезано, и не окажется часть в одном поле а часть в другом.
Ещё более весело обстоит дело с редактированием такого уродца. Опять же, единственный разумный/простой/надёжный способ - это редактировать текст в ОДНОМ элементе управления, а потом уже в коде распихивать его по разным полям.
В общем геморрой тот ещё.
Ни один разработчик в здравом уме не пошёл бы на это, если бы не то количество проблем, которое потенциально влечёт за собой использование memo полей...

Igor Korolyov
Только если всегда искать по tbl1.fld1+tbl2.fld2

Ну дык ясен пень, что только так. Что же касаемо редактирования, то тоже особых проблем нет. Я в таких случаях создаю шаблон (нечто похожее на область редактирования), где юзер резвится аж на 20 строчках. Потом полученное наименование можно обработать на предмет лишних пробелов, и далее наименование распихать по таблицам. Причем ежели наименование укоротилось так, что влазит в одну таблицу, то надо убрать уже ненужный "хвост" из второй таблицы. Как именно убрать - это уже другой вопрос.

Конечно, элементы гемора тут присутствуют. Но когда решение есть, его уже не надо в будущем заново придумывать.

Когда есть системы где не требуется всего этого геморроя, то остаётся только с улыбкой смотреть на героев продолжающих упорно жрать кактус
Если что, то для VFP банальный отказ от dbf хранилища в своё время устранил огромное количество глупейших проблем - да, конечно, появились и кое какие новые - но по крайней мере вопроса с разрезанием полей дабы не ввязываться в борьбу с memo уже точно не возникало

Igor Korolyov
Когда есть системы где не требуется всего этого геморроя, то остаётся только с улыбкой смотреть на героев продолжающих упорно жрать кактус

Дело в том, что отучить тех кто привык жрать кактус достаточно сложно, у них уже годами сложившиеся и работающие приложения, которые требуют только сопровождения и минимальных доработок. Не думаю, что в современных условиях тов. Симпле с нуля стал бы жрать кактус если имеется тортик.Если бы ему сейчас было лет 25 и ставилась задача по разработке нового приложения, не было бы этого спора и кактусов бы тоже не было

PS: Для Симпле: Только не нужно вспоминать недавнего студента с задачей на FPD 1, забудем его как страшный сон.

А что за "страшные" проблемы с memo. Вот, в большой таблице (ок 1Г), операторы пишут комментарии (размером с 50-100 байт), до/переписывают иногда. Короткие комменты (<200 байт в основном), процентах на 10 записей есть комменты. Так за 10-20 лет не пакал мемо (и таблицу), и размер FPT невелик (ок. 100М). Никаких проблем не испытывал. Чяднт?

() Если записи в мемо статичны (не изменяются, записали 1 раз и забыли), то вобще непонятно, чем плох мемо...

мемо чуть более сложен в починке (при тех же сбоях питания). cdx то хоть можно reindex-ом из резервной копии восстановить, а fpt - нет. Ну и он гораздо чаще чем сам dbf ломается в варианте "урезания в ноль", после чего только утилиты системного восстановления (типа восстановления удалённых файлов) могут помочь, да и то с шансами очень близкими к нулю (так же ломаются и cdx, но я повторюсь что это как раз некритично в плане ремонта). dbf гораздо реже ломаются таким макаром - 99% их "поломок" это рассинхронизация размера файла и счётчика записей в заголовке - ну ещё достаточно часто это сопровождается "наполовину" записавшейся последней записью (т.е. теряется по сути лишь 1 запись, а не ВСЁ).

мемо при shared режиме использования таблицы "распухает" - т.к. блоки в fpt не переписываются, а практически всегда добавляются новые. Да, для варианта использования write once это не так критично, но для активно изменяемых полей - запросто приводят к ситуации когда всего на пару тысяч записей в dbf имеем 2 гигабайтный fpt, куда уже "не лезут" новые блоки. Конечно же pack поможет, но и он сам по себе опасная штука (сбой во время этого процесса ОЧЕНЬ опасен для данных), да и не во всех системах допустим "регламентный простой".

Есть мнение, что в некоторых версиях фокса мемо поля ломаются "на ровном месте" - т.е. при совершенно безобидных с виду манипуляциях - я не могу этого ни подтвердить ни опровергнуть - лично у меня все сбои fpt файлов всегда были вызваны "внешними" причинами (чаще всего сбой сети - электрической или локальной). Но то что пару раз "обнулялся" dct (тоже ведь мемо-файл) при хитрой последовательности операций - это было.

Еженочное (и перед паком) копирование решает все эти "проблемы"

Оно то понятно - нужно уметь энтих кошек "правильно готовить"

От себя - помню было неимоверное облегчение когда слез с dbf/fpt/dct ... и правда расслабило сильно - ни тебе особой (критичной) заботы о размерах базы, ни тебе падений периодических, нормально работающие триггеры и т.п. ... тунеядство сплошное



Исправлено 1 раз(а). Последнее : AndyNigmatec, 30.01.18 17:11

Ну перелезть на "взрослую БД", которая "не ломается" (сама пакается когда надо) - это "решение" понятное. Но... хочется вот иметь маленькую прогу, без инсталяшки, скопировал, запустил - и вот маленькая БД... Прям обязательно надо плюнуть на DBF-ки... Ну может быть... Следующую прогу, если лет на 20 ей жить, то обязательно на МС СКУЛ, или кто еще делает вечные БД

of63
если лет на 20 ей жить, то обязательно на МС СКУЛ

of63
Еженочное (и перед паком) копирование решает все эти "проблемы"

Да дело ж не в том что "невозможно решить", а в том что огромная куча ненужных действий, ненужного кода сидит в программе...

К примеру, даже в 9-м фоксе, в папке FFC сидит утилитка runcode.prg
Она утратила свою актуальность с введением в VFP6SP3 возможности делать COMPILE в рантайме. Т.к. заменялась на буквально 5-6 строк. С появлением EXECSCRIPT это и вовсе свелось в один единственный вызов встроенной функции - при том с ГОРАЗДО большими возможностями (скажем описать динамически класс и откомпилировав создать объект). По моему это достаточно яркий пример, как облегчается жизнь если выкинуть замшелый хлам столетней давности