ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Есть прога по медицине ( с6.3 + MS SQL таблицы ) хотят вести всякие журналы протоколы наблюдений назначения лекартсв и прочее прочее
в общем море текстовой произвольной инфы
Хранить в таблицах sql если - там ограничения какие-то выползают по объему байт
Если пользовать поля типа memory то нет соответсвия в кларе при описании оной в dct
???
в общем море текстовой произвольной инфы
Хранить в таблицах sql если - там ограничения какие-то выползают по объему байт
Если пользовать поля типа memory то нет соответсвия в кларе при описании оной в dct
???
- morkovin
- Ветеран
- Сообщения: 909
- Зарегистрирован: 20 Июль 2005, 14:53
- Откуда: Volgograd, Russia
- Благодарил (а): 2 раза
- Поблагодарили: 3 раза
- Контактная информация:
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
типичная программа-библиотека. Работаешь с рубрикатором, в БД хранишь ссылки на файлы, аннотацию и скриншот обложки (первой страницы).в общем море текстовой произвольной инфы
WBR, morkovin
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
И в Кларионе и в SQL есть блобы( в MS SQL называются VARBINARY(MAX) - размер до 2 гигов) , в последних версиях MS SQL вроде можно распорядиться, чтобы хранились отдельно. По сравнению с автономным хранилищем файлов - несколько более высокий уровень надёжности и целостности данных. Другая проблема вопрос доступа - если программа имеет доступ к файлу, то и оператор тоже.
-
- ✯ Ветеран ✯
- Сообщения: 4999
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 21 раз
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Ну если это журнал, то хранение информации предполагается так (упрощённо): Дата, текст. Вот сколько текста предполагается ввести на дату? Хранить всё скопом - это не БД. Легче использовать Winword/talgat55 писал(а):Есть прога по медицине ( с6.3 + MS SQL таблицы ) хотят вести всякие журналы протоколы наблюдений назначения лекартсв и прочее прочее
в общем море текстовой произвольной инфы
We are hard at work… for you.
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
т.е. в dct в табл. mssql поле описываю как blob а в mssql ( 2008r2 ) какое поле можно - чтоб соответствовало blob ?Yufil писал(а): И в Кларионе и в SQL есть блобы( в MS SQL называются VARBINARY(MAX) - размер до 2 гигов) , в последних версиях MS SQL вроде можно распорядиться, чтобы хранились отдельно. По сравнению с автономным хранилищем файлов - несколько более высокий уровень надёжности и целостности данных. Другая проблема вопрос доступа - если программа имеет доступ к файлу, то и оператор тоже.
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1378
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 7 раз
- Поблагодарили: 1 раз
- Контактная информация:
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Есть несколько вариантов
Если текст но большой то лучше varchar(max) он же varchar (-1)
Если бинарные данные то image или varbinary(max)
http://www.sql.ru/forum/586310/image-il ... lov-v-baze
У нас все варианты в базе есть, где как )))
Если текст но большой то лучше varchar(max) он же varchar (-1)
Если бинарные данные то image или varbinary(max)
http://www.sql.ru/forum/586310/image-il ... lov-v-baze
У нас все варианты в базе есть, где как )))
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Я везде пользовал Image, даже для текстов. А блобы паковал через Zlib, чтобы поменьше места занимали. Мож, и зря...
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Немного отойдя от конкретного случая.
Мы в своей системе хранили на файловом сервере тысячи файлов с изображениями (обязательная сертификация знаете ли).
Причём это были часто цветные сканы формата A4. А в MS SQL хранили только пути к этим файлам.
Честно говоря, не очень представляю, что бы мы делали с таким объёмом базы, начни затаскивать мы их в BLOB.
Плюс это всегда лишние операции сохранения/извлечения. А если их много (ну то есть очень много)?!
Например при печати сертификатов. Условно: 2000 накладных * 10 позиций * 5 сканов на позицию = 100000 извлечений из BLOB. На следующий день всё повторяется. Даже просто распаковка из zip становится непозволительной роскошью.
Мы в своей системе хранили на файловом сервере тысячи файлов с изображениями (обязательная сертификация знаете ли).
Причём это были часто цветные сканы формата A4. А в MS SQL хранили только пути к этим файлам.
Честно говоря, не очень представляю, что бы мы делали с таким объёмом базы, начни затаскивать мы их в BLOB.
Плюс это всегда лишние операции сохранения/извлечения. А если их много (ну то есть очень много)?!
Например при печати сертификатов. Условно: 2000 накладных * 10 позиций * 5 сканов на позицию = 100000 извлечений из BLOB. На следующий день всё повторяется. Даже просто распаковка из zip становится непозволительной роскошью.
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Конкретный случай, конечно, очень важен... Но вот в какой-то момент выяснилось, что несколько тысяч документов пропали. Почему - а неизвестно... И в каталоге сотни подкаталогов, в каждом десятки тысяч записей (даже с учётом разбивки на подкаталоги), вход в каталог и поиск файла занимает секунды, а то и десятки секунд, так что не всё однозначно. Понятно, что документы надо хранить на отдельном сервере, как-то ограничить к ним прямой доступ (может быть, поднять web-сервер, выдающий документ по запросу), завести отдельный процесс только для печати сертификатов. В общем, где-то так...
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Не знаю, открою ли я какую-то тайну, но, раз уж заговорили о хранении тысяч файлов в файловой системе, то, чтобы не тратилось время на поиск файла в каталоге, который, как мы знаем, действительно происходит перебором, было придумано очень простое, но эффективное решение, позволяющее доставать необходимые файлы практически мгновенно.
Допустим 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, даже путь как таковой не было смысла хранить, он генерировался динамически во время печати.
-
- ✯ Ветеран ✯
- Сообщения: 4999
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 21 раз
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Дело больше в безопасности. Мы тоже с этим столкнулись. Нет желания хранить огромное количество документов (самых разных) в самой базе, храним на выделенном сервере. Но при этом приходится давать доступ пользователю на этот сервер, чтобы из программы можно было видеть файлы. а полностью защититься от удаления или исправления видимо нельзя. Админы не могут этого сделать. Поэтому просят придумать какую-нибудь прокладку.
We are hard at work… for you.
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Тогда запись сертификата в каталог потребует создания десятка подкаталогов, но это детали...
Видел такой вариант, правда, там использовалось шестнадцатеричное представление наименования, чтобы не болела голова от неразрешённых символов в имени файла. Количество подкаталогов ('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, но это тиражируемое приложение сравнительно небольшого объёма.
Но вопросы целостности и доступа остались.
Видел такой вариант, правда, там использовалось шестнадцатеричное представление наименования, чтобы не болела голова от неразрешённых символов в имени файла. Количество подкаталогов ('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 раз.
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Самый простой вариант - поднять ftp или http сервер и скачивать файлы оттуда, доступ только с логином и паролем...kreator писал(а): Дело больше в безопасности. Мы тоже с этим столкнулись. Нет желания хранить огромное количество документов (самых разных) в самой базе, храним на выделенном сервере. Но при этом приходится давать доступ пользователю на этот сервер, чтобы из программы можно было видеть файлы. а полностью защититься от удаления или исправления видимо нельзя. Админы не могут этого сделать. Поэтому просят придумать какую-нибудь прокладку.
-
- ✯ Ветеран ✯
- Сообщения: 4999
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 21 раз
ВВОД И ХРАНЕНИЕ ТЕКСТОВ В КЛАРИОН
Нужно не скачивать, а с интерфейса программы их видеть. Например, фото.Yufil писал(а):Самый простой вариант - поднять ftp или http сервер и скачивать файлы оттуда, доступ только с логином и паролем...
We are hard at work… for you.