ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
talgat55
Ветеран
Сообщения: 307
Зарегистрирован: 11 Сентябрь 2008, 12:53
Благодарил (а): 2 раза

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение talgat55 »

Есть прога по медицине ( с6.3 + MS SQL таблицы ) хотят вести всякие журналы протоколы наблюдений назначения лекартсв и прочее прочее
в общем море текстовой произвольной инфы
Хранить в таблицах sql если - там ограничения какие-то выползают по объему байт
Если пользовать поля типа memory то нет соответсвия в кларе при описании оной в dct
???
Аватара пользователя
morkovin
Ветеран
Сообщения: 908
Зарегистрирован: 20 Июль 2005, 14:53
Откуда: Volgograd, Russia
Благодарил (а): 2 раза
Поблагодарили: 3 раза
Контактная информация:

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение morkovin »

в общем море текстовой произвольной инфы
типичная программа-библиотека. Работаешь с рубрикатором, в БД хранишь ссылки на файлы, аннотацию и скриншот обложки (первой страницы).
WBR, morkovin
talgat55
Ветеран
Сообщения: 307
Зарегистрирован: 11 Сентябрь 2008, 12:53
Благодарил (а): 2 раза

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение talgat55 »

так и делаю в принципе
Yufil
Ветеран движения
Сообщения: 1277
Зарегистрирован: 16 Май 2006, 14:34
Контактная информация:

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение Yufil »

И в Кларионе и в SQL есть блобы( в MS SQL называются VARBINARY(MAX) - размер до 2 гигов) , в последних версиях MS SQL вроде можно распорядиться, чтобы хранились отдельно. По сравнению с автономным хранилищем файлов - несколько более высокий уровень надёжности и целостности данных. Другая проблема вопрос доступа - если программа имеет доступ к файлу, то и оператор тоже.
kreator
✯ Ветеран ✯
Сообщения: 4960
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 6 раз
Поблагодарили: 19 раз

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение kreator »

talgat55 писал(а):Есть прога по медицине ( с6.3 + MS SQL таблицы ) хотят вести всякие журналы протоколы наблюдений назначения лекартсв и прочее прочее
в общем море текстовой произвольной инфы
Ну если это журнал, то хранение информации предполагается так (упрощённо): Дата, текст. Вот сколько текста предполагается ввести на дату? Хранить всё скопом - это не БД. Легче использовать Winword/
We are hard at work… for you. :)
talgat55
Ветеран
Сообщения: 307
Зарегистрирован: 11 Сентябрь 2008, 12:53
Благодарил (а): 2 раза

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение talgat55 »

Yufil писал(а): И в Кларионе и в SQL есть блобы( в MS SQL называются VARBINARY(MAX) - размер до 2 гигов) , в последних версиях MS SQL вроде можно распорядиться, чтобы хранились отдельно. По сравнению с автономным хранилищем файлов - несколько более высокий уровень надёжности и целостности данных. Другая проблема вопрос доступа - если программа имеет доступ к файлу, то и оператор тоже.
т.е. в dct в табл. mssql поле описываю как blob а в mssql ( 2008r2 ) какое поле можно - чтоб соответствовало blob ?
Аватара пользователя
RaFaeL
✯ Ветеран ✯
Сообщения: 1376
Зарегистрирован: 24 Март 2009, 17:59
Откуда: НН
Благодарил (а): 7 раз
Поблагодарили: 1 раз
Контактная информация:

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение RaFaeL »

Есть несколько вариантов
Если текст но большой то лучше varchar(max) он же varchar (-1)
Если бинарные данные то image или varbinary(max)
http://www.sql.ru/forum/586310/image-il ... lov-v-baze
У нас все варианты в базе есть, где как )))
Yufil
Ветеран движения
Сообщения: 1277
Зарегистрирован: 16 Май 2006, 14:34
Контактная информация:

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение Yufil »

Я везде пользовал Image, даже для текстов. А блобы паковал через Zlib, чтобы поменьше места занимали. Мож, и зря...
Shur
Ветеран
Сообщения: 384
Зарегистрирован: 02 Июль 2011, 18:49

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение Shur »

Немного отойдя от конкретного случая.
Мы в своей системе хранили на файловом сервере тысячи файлов с изображениями (обязательная сертификация знаете ли).
Причём это были часто цветные сканы формата A4. А в MS SQL хранили только пути к этим файлам.
Честно говоря, не очень представляю, что бы мы делали с таким объёмом базы, начни затаскивать мы их в BLOB.
Плюс это всегда лишние операции сохранения/извлечения. А если их много (ну то есть очень много)?!
Например при печати сертификатов. Условно: 2000 накладных * 10 позиций * 5 сканов на позицию = 100000 извлечений из BLOB. На следующий день всё повторяется. Даже просто распаковка из zip становится непозволительной роскошью.
Yufil
Ветеран движения
Сообщения: 1277
Зарегистрирован: 16 Май 2006, 14:34
Контактная информация:

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение Yufil »

Конкретный случай, конечно, очень важен... Но вот в какой-то момент выяснилось, что несколько тысяч документов пропали. Почему - а неизвестно... И в каталоге сотни подкаталогов, в каждом десятки тысяч записей (даже с учётом разбивки на подкаталоги), вход в каталог и поиск файла занимает секунды, а то и десятки секунд, так что не всё однозначно. Понятно, что документы надо хранить на отдельном сервере, как-то ограничить к ним прямой доступ (может быть, поднять web-сервер, выдающий документ по запросу), завести отдельный процесс только для печати сертификатов. В общем, где-то так...
Shur
Ветеран
Сообщения: 384
Зарегистрирован: 02 Июль 2011, 18:49

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение Shur »

Yufil писал(а):... И в каталоге сотни подкаталогов, в каждом десятки тысяч записей (даже с учётом разбивки на подкаталоги), вход в каталог и поиск файла занимает секунды, а то и десятки секунд...
Не знаю, открою ли я какую-то тайну, но, раз уж заговорили о хранении тысяч файлов в файловой системе, то, чтобы не тратилось время на поиск файла в каталоге, который, как мы знаем, действительно происходит перебором, было придумано очень простое, но эффективное решение, позволяющее доставать необходимые файлы практически мгновенно.
Допустим ID сертификата в базе 0123456789 и файлы 1.jpg, 2.jpg и т.д. Тогда они должны храниться как-то так \\sertificates\0\1\2\3\4\5\6\7\8\9\1.jpg, \\sertificates\0\1\2\3\4\5\6\7\8\9\2.jpg.
Тогда это гарантирует, что файл будет найден не более чем за 100 шагов в каталогах (максимально по 10 на каждом уровне иерархии каталогов). Поэтому, зная ID, даже путь как таковой не было смысла хранить, он генерировался динамически во время печати.
kreator
✯ Ветеран ✯
Сообщения: 4960
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 6 раз
Поблагодарили: 19 раз

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение kreator »

Дело больше в безопасности. Мы тоже с этим столкнулись. Нет желания хранить огромное количество документов (самых разных) в самой базе, храним на выделенном сервере. Но при этом приходится давать доступ пользователю на этот сервер, чтобы из программы можно было видеть файлы. а полностью защититься от удаления или исправления видимо нельзя. Админы не могут этого сделать. Поэтому просят придумать какую-нибудь прокладку.
We are hard at work… for you. :)
Yufil
Ветеран движения
Сообщения: 1277
Зарегистрирован: 16 Май 2006, 14:34
Контактная информация:

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение Yufil »

Тогда запись сертификата в каталог потребует создания десятка подкаталогов, но это детали...
Видел такой вариант, правда, там использовалось шестнадцатеричное представление наименования, чтобы не болела голова от неразрешённых символов в имени файла. Количество подкаталогов ('0000' - 'ffff') и их глубина существенно меньше

В прошлом году делал программу выгрузки данных из обучающих программ с последующей конвертацией в javascript
База данных состоит из отдельных экранов (где-то от 100 до 1000) , в состав экрана входят разные элементы, в результате разгрузка экрана 'screen1' создаёт подкаталоги

hdump\source\screen1,
hdump\source\screen1\text,
hdump\source\screen1\screen1_images,
hdump\source\screen1\test

и так для каждого экрана. Но перед началом работы каталог hdump надо, естественно, очистить. Так вот, этот процесс занимал несколько минут, поскольку надо было построить дерево подкаталогов, удалить файлы, а потом - удалить каталоги.
После жалоб стал сбрасывать все файлы в один каталог
hdump\source\screen1.text.html, hdump\source\screen1.screen1_images.1.jpg, hdump\source\screen1.test.question.1.xml - где-то так... В итоге скорость работы программы выросла в разы. Так что глубокая прогулка по каталогам - тоже болезненный вопрос...

Кстати, в обучающих программах данные (картинки, форматированные тексты, контейнеры с форматами экранов, контейнеры с тестами, скрипты) - всё хранится в Blob, но это тиражируемое приложение сравнительно небольшого объёма.

Но вопросы целостности и доступа остались.
Последний раз редактировалось Yufil 29 Март 2017, 11:57, всего редактировалось 1 раз.
Yufil
Ветеран движения
Сообщения: 1277
Зарегистрирован: 16 Май 2006, 14:34
Контактная информация:

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение Yufil »

kreator писал(а): Дело больше в безопасности. Мы тоже с этим столкнулись. Нет желания хранить огромное количество документов (самых разных) в самой базе, храним на выделенном сервере. Но при этом приходится давать доступ пользователю на этот сервер, чтобы из программы можно было видеть файлы. а полностью защититься от удаления или исправления видимо нельзя. Админы не могут этого сделать. Поэтому просят придумать какую-нибудь прокладку.
Самый простой вариант - поднять ftp или http сервер и скачивать файлы оттуда, доступ только с логином и паролем...
kreator
✯ Ветеран ✯
Сообщения: 4960
Зарегистрирован: 28 Май 2009, 15:54
Откуда: Москва
Благодарил (а): 6 раз
Поблагодарили: 19 раз

ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН

Сообщение kreator »

Yufil писал(а):Самый простой вариант - поднять ftp или http сервер и скачивать файлы оттуда, доступ только с логином и паролем...
Нужно не скачивать, а с интерфейса программы их видеть. Например, фото.
We are hard at work… for you. :)
Ответить