Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » InterBase и FireBird: вопросы по работе и их решение

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

Открыть новую тему     Написать ответ в эту тему

delover

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
druff
Все правильно кроме изменения условий.  

Цитата:
Или регулярно запускать скрипт, который исправит ошибки

Это не ошибки, база данных организаций переодически обновляется, исправление этих данных будет существовать только до очередного обновления. Теперь база клиентов,... Она - заполняется наполовину вручную путём выдирания контента с сайтов и вордовских документов, где дефис номера телефона это длинный дефис документа ворд. Бороться с этим (ИМХО) не тактично. Да и невероятное удивление пользователей, "я же только что ввела всю информацию, вот она, а вот она её не находит"...

Цитата:
а нельзя результаты этого сложного расчёта тоже хранить в базе?

Надобы, но сиё возможно для уже сформировавшегося и удовлетворяющего по всем параметрам вычисления. Пока моё вычисление лучше чем T9, но близко к телефонной программе T9. Требования нарабатываются.
 
OOO, я взял для примера. Другой пример:
Магазин Продукты и Магазин Дюймовочка. Слово магазин совпало:
Eq=Магазин   ...  dA:Продукты  ...    dB:Дюймовочка
Магазин=4500 раз в справочнике
Продукты=1500 раз в справочнике
Дюймово4ка=4 раза в справочнике.
-
Вывод - непохожы
Оптовый рынок Дюймовочка, тут похожи.
 
Добавлено:
Суть
Супер цель: Привести базу к условиям уникальности записи об организации.
Цель: Дать инструментарий для этого.
Почему в примере был distinct:
Это отношение многих ко многим. Мои вычисления то же самое многие ко многим. Каждая просматриваемая организация в фоновом режиме сравнивается с каждой организацией являющейся клиентом.
Почему нетактично бороться с ООО:
Аппарат сравнения строк с условием независимости от языка отработан ровно на столько же на сколько AnsiCompareText. Есть и сравнения и преобразования и сортировки. Меняются только названия функций. Ну и зачем бороться с проблеммой которой нет? Наобарот надо поощрять людей.
 
Добавлено:
В идеале
Мне бы иметь на клиенте этот пресловутый джойн в виде айдишников и записи о положительном результате сравнения тоже в виде айдишников падающих в калкфилд. Плюсы - мало памяти, быстый доступ к результатам, абсолютно прозрачная фоновая работа с расчётами не на серваке. В общем тупо клиентдатасет, который абсолютно безполезен - строки айдишников превышают 2-4кб.

Всего записей: 1395 | Зарегистр. 25-06-2007 | Отправлено: 15:03 16-08-2011 | Исправлено: delover, 15:04 16-08-2011
TuMOXA123

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Если не в тему, дайте ссылку на хороший форум по firebird.
 
Есть ли какая-нибудь возможность запустить Firebird 2.5 на FreeBSD как standalone сервер (не через inetd\xinetd) ?

Всего записей: 456 | Зарегистр. 27-01-2003 | Отправлено: 15:37 22-08-2011
X11



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
sql.ru
ibase.ru

----------
/не мы такие, жизнь такая/

Всего записей: 3253 | Зарегистр. 24-11-2005 | Отправлено: 15:47 22-08-2011
AlexPetrovich

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
delover

Цитата:
что ID - айдишники найденные вне базы, на клиенте, бесполезны для сервака. 5000 айдишников это уже 32 кб в запросе...

А если загнать эти айдишники во временную таблицу (GTT) и выполнять джойн с ней ?

Всего записей: 87 | Зарегистр. 08-05-2003 | Отправлено: 17:09 22-08-2011
delover

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
1. Делаю селект с IB таблицы, который возвращает OutOfMemory.
2. Делаю унидиректионал и копирую в собственный датасет всю таблицу (таблица 180мб).  
3. Утраиваю свои данные в датасете, те добавляю ещё IB два раза.
4. Копирую в MSSQL для прикола.
5. MSSQL фечит всё (3 исходных таблицы) без унидеректинала больше 1 секунды.
6. Мой клиентдатасет разумеется чуть меньше одной секунды.
7. IB без унидиректинала призадумывается, но так же OutOfMemory, не сделав 1 третьей.
8. Прихожу к другу - он сидит за компиком - качает парнуху. Говорю скопируй вот эту, а он мне - ты чё типа лох чтоли - невидишь она 300мб. Я говорю и типа чё? Он- это либо фуфловое качество, либо продолжительность 20 секунд, наф надо.
 
Ребят это не смешно 180мб - OutOfMemory? А самая дешевейшая память которую ещё возможно купить разве не 512мб?
 
AlexPetrovich
Пока это единственный вариант который я уже делал. Тогда сервак ещё не поддерживал временные таблицы. Пришлось написать очень сложную математическую машину. Так как я уже говорил - можно организовать клиентдатасет, но...! Придётся организовывать датасет, плюсом организовывать временные выборки для джойнов, то есть заточить ту мат махину которую я бы не хотел использовать.  
Я вполне согласен с ограничением самого SQL запроса на 2кб - это заглаза. Но я не отоношу набор цыфр с запятыми в SQL синтаксис. Строка длиной 2мб с цыфрами и запятыми парсится в TIntegerList не больше 20 миллисекунд на друвнем компике.
 
Добавлено:
ps
Где бы память такую купить чтобы меньше 280мб.

Всего записей: 1395 | Зарегистр. 25-06-2007 | Отправлено: 07:33 24-08-2011
druff

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
delover
в firebird.conf есть несколько настроек, влияющих на размер памяти используемой сервером. Можно даже базу хранить не на диске, а в RAM

Всего записей: 402 | Зарегистр. 14-11-2006 | Отправлено: 10:44 24-08-2011
delover

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Тогда порабы дефолты конфига тож поправить...
 
pps
И опять же речь не идёт о снятии ограничений, а о лишь пересмотре их размеров. Не надо ломать математику, а только проследить как оптимально повысить допустимые размеры. Речь не идёт о телефонах которые не потдерживают IB компоненты и у которых памяти меньше 256мб. Такие телефоны ещё можно купить, но до IB они вряд ли доживут. Речь о средних серверах которых много и реальный промышленный эффект в основном от них 2Gb-4Gb, клиенты 1Gb-4Gb. Большое количество таких клиентов, где 1 или более Гигобайт оперативки, и имеется основная для их фирмы программа, которая не в состоянии справляться со 180мб. Это не критика, а сожаление по поводу очень достойного матаппарата и констатация того, что популярность этого аппарата по очевидным (хотя и глупым) причинам будет сильно уменьшатся. Желательно бы без этого (извините меня ламера даже не знаю какие настройки в конфиге влияют на выпадание OutOfMemory).  
 
Добавлено:
по поводу айдишников - есть простая хранимка (хранимая процедура SplitIDs) которая парсит строку айдишников переданную параметром 64кб и возвращает таблицу для джойна, но такая штука тоже далкео не у всех есть.

Всего записей: 1395 | Зарегистр. 25-06-2007 | Отправлено: 11:33 24-08-2011 | Исправлено: delover, 12:50 24-08-2011
druff

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
delover
Я считаю, что классические OLTP СУБД не предназначены для таких задач (вытягивание клиентом такого большого количества данных в одной транзакции). У меня, например, ни разу ещё не возникала проблема с нехваткой памяти, хотя базы у заказчиков доходят до 20гиг при 50и клиентах. Все большие обработки данных обычно проходят на стороне сервера (кстати в сторону UDF не копали? может они помогут)

Всего записей: 402 | Зарегистр. 14-11-2006 | Отправлено: 14:11 24-08-2011
delover

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
druff
Копал. К примеру вы имеете на одну модель изделия справочник толщиной с энциклопедию. Таких моделей на изделие несколько десятков, таких изделий у фирмы несколько десятков, таких фирм несколько десятков. Естественно это несколько баз с одинаковой структурой. И вы заполнив эти базы - тоесть потратив огромное количество человекочасов собираетесь их продать потребителью. 1 потребитель купил и раздал эти справочники бесплатно, Вас это наверно чемто не устроит? Подумаете зашифровать базу и защитить прогу чемто типо СтарФорс? Хорошее решение, правдо защита на каждую версию программы оплачивается Вами крупненькой суммой. И тут находится гениальный программист который предлагает расшифровывать данные в UDFках и использовать фильтрацию селекта по like на расшифрованный текст. Это веть быстрее? Круто! Тут же потребитель номер 2 легонько вскрывает UDF и все справочники и так же раздаёт их бесплатно. Себестоимость СтарФорс и заполнения вдруг оказалась намного больше выручки. А подобное случалось?

Всего записей: 1395 | Зарегистр. 25-06-2007 | Отправлено: 22:26 25-08-2011 | Исправлено: delover, 22:27 25-08-2011
delover

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
То что касается моей текущей задачи, так и надо сделать - всё засунуть в UDF. Спасибо, мне пришлось преодолеть свой комплекс и свои тормоза, но это здоровское решение. В задаче ничё секретного вопервых, вовторых для Линукса саппорт пока не планировался. ))) Да и почти удалось реанимировать функции автоматического обновления любых файлов.

Всего записей: 1395 | Зарегистр. 25-06-2007 | Отправлено: 05:42 26-08-2011
druff

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
delover
UDF точно так же будут работать под nix, если писать их на Lazarus.
 
насчёт защиты данных я пока что не особо беспокоился.. Т.к. в моём случае все данные в базе принадлежат заказчику и не в моём праве закрывать к ним доступ. Меня больше заботит защита собственных алгоритмов, и, по возможности, структуры самой базы.

Всего записей: 402 | Зарегистр. 14-11-2006 | Отправлено: 10:20 26-08-2011
TuMOXA123

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Меня больше заботит защита собственных алгоритмов, и, по возможности, структуры самой базы.

 
Можно стереть исходный код процедур и триггеров.  
 
Update RDB$TRIGGERS set RDB$TRIGGER_SOURCE = '';
Update RDB$PROCEDURES set RDB$PROCEDURE_SOURCE = '';
 
А структуру таблиц по-любому увидят

Всего записей: 456 | Зарегистр. 27-01-2003 | Отправлено: 15:19 26-08-2011
druff

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
TuMOXA123
Текст ХП можно не только стереть, но и изменить
 
А структуру сделать нечитаемой. Т.е. названий всех объектов.. Перед сборкой релиза для клиентов - провести обфускацию названий, выбранных разработчиком таблиц, полей, ХП и т.д. Попробуй потом разберись в таких данных

Всего записей: 402 | Зарегистр. 14-11-2006 | Отправлено: 16:24 26-08-2011 | Исправлено: druff, 16:26 26-08-2011
delover

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
druff

Цитата:
Т.к. в моём случае все данные в базе принадлежат заказчику и не в моём праве закрывать к ним доступ.

Это не совсем верно если рассматривать для примера D2010. Данные заказчика в целости - они не зашифрованы. Однако без Вашего вмешательства их получить бывает достаточно трудно. На гриде они видны а вот чтобы их сохранить надо например иметь ввиду, что компоненты сами умеют создавать филды, как это делается:
 

Код:
DefaultFieldClasses: array[TFieldType] of TFieldClass = (
DB.pas
    TMemoField,                { ftMemo }
IBCustomDataSet.pas
    TWideMemoField,     { ftMemo }
function ADOTypeToFieldType(const ADOType: DataTypeEnum;
ADODB.pas
    adLongVarChar: Result := ftMemo;
    adLongVarWChar: Result := ftWideMemo;

 
Очевидно что только IB создаёт TWideMemoField  
 

Код:
if MyBlobField.BlobType=IBBlobField.BlobType then
  MyBlobField.Assign(IBBlobField);

 
В результате чтение в анси строку из IB потока в котором сохранили wide строку. Естественно кроме первой буквы ничего нет. Но вот если бы Вы зашифровали данные, то у заказчику было бы проще их достать обратившись к Вам. )))

Всего записей: 1395 | Зарегистр. 25-06-2007 | Отправлено: 19:56 26-08-2011 | Исправлено: delover, 21:40 26-08-2011
1959pma



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Удалено

Всего записей: 224 | Зарегистр. 09-10-2010 | Отправлено: 15:37 28-08-2011 | Исправлено: 1959pma, 15:37 28-08-2011
pzaytsev

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Кто может рассказать что-то познавательного о технологии MDT от DevRace?

Всего записей: 401 | Зарегистр. 22-08-2005 | Отправлено: 23:30 01-09-2011
Tantos



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
MDT - это технология Firebird 2+, а не Devrace.
По вашей же ссылке 2 статьи по MDT. В чем вопрос-то?

----------
Чем больше узнаю людей, тем больше люблю компьютеры.

Всего записей: 1038 | Зарегистр. 31-05-2005 | Отправлено: 06:49 02-09-2011
druff

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
MDT - это технология Firebird 2+, а не Devrace.  

 
В каком смысле? Насколько я помню, это технология при которой часть базы кэшируется на клиенте.

Всего записей: 402 | Зарегистр. 14-11-2006 | Отправлено: 11:10 02-09-2011
pzaytsev

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Tantos
 
Вопрос был, собственно, к практикам. Есть ли смысл копать в сторону MDT? Какие подводные камни? Есть ли реальный прирост производительности? Насколько разгрузился основной сервер БД?
 
Или кто видел ссылки на статьи по данному поводу? Кроме деврэйсовских.
 
Добавлено:

Цитата:
В каком смысле? Насколько я помню, это технология при которой часть базы кэшируется на клиенте.

 
Не просто кэшируется на клиенте, а кэшируется на ОДНОМ ИЗ КЛИЕНТОВ.

Всего записей: 401 | Зарегистр. 22-08-2005 | Отправлено: 12:54 02-09-2011
druff

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
pzaytsev

Цитата:
а кэшируется на ОДНОМ ИЗ КЛИЕНТОВ.

т.е.? какой смысл на одном клиенте кэшировать базу, а на другом - нет?

Всего записей: 402 | Зарегистр. 14-11-2006 | Отправлено: 16:59 02-09-2011
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » InterBase и FireBird: вопросы по работе и их решение


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru