Имеет ли смысл выбирать IB

← →
Sectey (2003-10-20 17:02) [0]

Есть есть файл-сервер с объемами таблиц преблезительно 1,5 Г.
Решили переходить на SQL сервер, имеет ли смысл, выбирать IB?

← →
mOOx_ (2003-10-20 17:34) [1]

А сколько в базе таблиц? Как часто они пополняются? Хватит ли средств использовать Оракл? И ... т.д. и т.п. :)

← →
Малиновский Владимир (2003-10-20 18:21) [2]

Да нормально, только, если база будет расширяться, перейдите с FAT32 на что-либо типа NTFS, а то грохнется база.

← →
kaif (2003-10-21 03:01) [3]

Учти, что IB хранит строки без концевых пробелов. Это значит, что база данных dBase, например, которая хранит концевые пробелы при перемещении в IB может потерять свой объем раз в шесть, как минимум. Так что может есть смысл переходить. А вообще лучше всего попробовать перекачать самые большие накопители (их не может быть много), а там уже принимать решение.

← →
Danilka (2003-10-21 08:18) [4]

[3] kaif © (21.10.03 03:01)
разве?
varchar хранится на серваке также как и char, иначе все записи были-бы разной длины и была-бы куча гемороя, начиная от скорости, заканчиая невозможностью писать записи на место удаленных записей.
а вот на клиента выкидывается обрезанным. и то, в дятле так делается, и, кажется, в последнем фиребирде (точно не помню), а в других верчиях обрезаются пробелы уже на клиенте.
то-есть, в лучшем случае экономится трафик.

но я могу и ошибаться :))

← →
Sectey (2003-10-21 08:18) [5]

Просто встал вопрос о переходе на SQL сервер, это порядком 60 машин основного офиса. При этом там история рознечных продаж по 15 аптекам, справится или IB или стоит всеже поставить что то посерьезней, MSSQL или Oracle ?

← →
Sergey13 (2003-10-21 08:33) [6]

2Sectey © (20.10.03 17:02)
>Есть есть файл-сервер с объемами таблиц преблезительно 1,5 Г...
>это порядком 60 машин основного офиса. При этом там история рознечных продаж по 15 аптекам
И у вас все это сейчас крутится на файл сервере?!!! И вопрос только встал? Ни фига себе. 8-()

← →
Sectey (2003-10-21 08:45) [7]

>Sergey13 ©
Все работает более-менее, НО прогресса минимум, оснавные задачи, клиперовские, А вот делфи со своей аналитако затыкается :-((

← →
Danilka (2003-10-21 08:48) [8]

Тут проскакивали сообщения о базах на IB объемом в 930 Гиг. Но сам я больших баз на нем не видел, поэтому сказать на основе опыта не могу.

← →
Sergey13 (2003-10-21 09:00) [9]

2Sectey © (21.10.03 08:45) [7]
>Все работает более-менее, НО прогресса минимум, оснавные задачи, клиперовские, А вот делфи со своей аналитако затыкается :-((
Секундочку.
1.Ты хочешь сказать, что делфа хреновее клиппера анализирует? Не понял. Поподробнее плиз, в чем выражается.
2. А у вас вообще файл-сервер есть? Или 1.5 Г это суммарный объем локальных таблиц на разных машинах? Данные вы локально молотите или все таки по сети?

← →
Anatoly Podgoretsky (2003-10-21 09:02) [10]

Danilka © (21.10.03 08:18) [4]
Именно так и есть и varchar и char хранятся на сервере без концевых пробелов и все записи были-бы разной длины, но гемороя никакого нет, и это не касается разработчика, как сервер хранит, что либо. Многие сервера хранят именно так, большая экономия места и может тебе покажется парадоксом но и ускорение работы, из за резкого уменьшения количества байтов.
Тебя же не волнует как работает string в Дельфи, а работает он также.

Sectey © (21.10.03 08:18) [5]
Из трех указаных баз, я бы выбрал MSSQL, он находится посредине и у него прекрасный утиль и неплохая маштабируемость. Оракл не экономичен.

← →
Малиновский Владимир (2003-10-21 12:09) [11]

Однако ожидается гемор при переходе с .DBF в .GDB - в основном при переделке клиентских приложений. В Delphi, в отличии от Clipper, не так обрабатываются функции дат, строки, Decimal"s и проч. А транзакции...
Еще, обычно при переделке используют BDE и компоненты типа TTable, а потом долго ругаются на квадратность Object Pascal"я и всего "этого долбаного Delphi". Если проект большой, нанимай опытного разработчика со стороны.
Хотя, может, справишься.

← →
Sergey_Masloff (2003-10-21 22:15) [12]

Sectey © (21.10.03 08:18) [5]
см.
>Anatoly Podgoretsky © (21.10.03 09:02) [10]
>Из трех указаных баз, я бы выбрал MSSQL, он находится посредине >и у него прекрасный утиль и неплохая маштабируемость. Оракл не >экономичен.
Вообще я например гораздо лучше знаю IB и Oracle но и то соглашусь что для базы в несколько ГБ и 50-70 пользователей MSSQL будет получше. Больше 100 я все же за Oracle.

← →
kaif (2003-10-22 00:30) [13]

Логика работы с таблицами в блокировочнике MSSQL возможно будет ближе к клипперовской, чем в многоверсионнике IB. И MSSQL я думаю есть масса всяких утилит для закачки из dbf , а под IB придется руками писать (или использовать DataPump, который я не уверен, что может с дос-кодировками разобраться, если они разные в разных таблицах, а такое бывает сплошь и рядом).
Хотя я, как поклонник IB все же попробовал бы оба варианта. Все познается в сравнении.

2 Danilka © (21.10.03 08:18) [4]
[3] kaif © (21.10.03 03:01)
разве?
varchar хранится на серваке также как и char, иначе все записи были-бы разной длины и была-бы куча гемороя, начиная от скорости, заканчиая невозможностью писать записи на место удаленных записей.

Почитай документацию IB.

InterBase compresses trailing blanks when it stores fixed-length strings, so data with trailing blanks uses the same amount of space as an equivalent variable-length string. When the data is read, InterBase reinserts the blanks. This saves
disk space when the length of the data items varies widely.

Все строки хранятся без концевых пробелов: и char и varchar. Просто char добиваются концевыми пробелами до ширины поля при чтении, а varchar не добиваются.
Как это реализовано физически - я не знаю. Только знаю, что при нехватке места аллокируются новые страницы.
Не надо путать с одной особенностью полей TStringField клиента. которая выражается в том, что пустая строка "" почему-то превращается в NULL перед посылкой на сервер. Возможно, именно эта неприятная фича и вызывает путаницу и всякие недоразумения.

← →
kaif (2003-10-22 00:40) [14]

В любом случае я бы посоветовал оценить вначале реальный объем базы в байтах. Например, написать программку, которая посчитает процент пробелов в dbf-ах. Поля даты также будут сокращены по ширине, так как дата в IB занимает 4 байта, а в dbf-е 8 не то 10 байт. С числовыми полями та же фигня. Например, integer занимает 4 байта в IB, а в dbf под это поле может быть выделено 8-10 символов. Разумеется, если базы хорошо нормализованы, то скорее всего строковых полей в основных накопителях вообще нет, а используются лишь ссылки на справочники. Но тут могут встретиться подводные камни. Например, для экономии места в dbf-ах разработчики-профессионалы применяли кодирование полей ID всякими методами, превращая, например, 6-значные числа в 3-значные буквенно-сивольные конструкции. Тогда при перекачке можно столкнуться с неприятной ситуацией: вместо принятых на серваках способов использовать под ID поля типа integer, приходится заводить поля типа char(3) и потом как-то превращать все это обратно в integer.
В общем, нужно очень внимательно изучить таблицы,прежде чем вообще принимать какое-то решение. В большинстве случаев перенос "в лоб" попросту не работает из-за разных подходов (в клиппере - навигация по данным, в SQL - работа с множествами)

← →
Anatoly Podgoretsky (2003-10-22 09:03) [15]

Sergey_Masloff (21.10.03 22:15) [12]
Да все эти три системы справится, не тот объем и справятся на порядки с большими размерами и нагрузкой. Тенцера знаешь?
У него как раз MSSQL и нагрузки по объему, по одновременно работающим пользователям, по количеству запросов в секунду - тысячи и никаких жадоб на производительность. С другой стороны любой мощный сервер можно поставить на колени и при меньшей нагрузке. На указаных объемах я бы остановился или на IB или на MSSQL

kaif © (22.10.03 00:30) [13]
Перекачка разовая задача, не стоит на этом состредоточивать внимание, тяжелее с идеологией

kaif © (22.10.03 00:40) [14]
В xBase строки занимают именно столько места, сколько заявлено +1, поэтому экономия места может быть значительная. Еще драматичнее обстоит дело с мемо полями, выделяется блока кратными 512 для dBase и немного шире возможности у FoxPro, но обеих к размеру блока добавляется еще 10 байт на указатель.

Основной смыцсл как раз состоит в смене технологии, особенно при таких размерах, но миграция вряд ли будет легкой, груз старой технологии долго будет оказывать свое тлетворное влияние и вряд ли старая система сделана продумано и на основе SQL.

← →
Sergey_Masloff (2003-10-22 15:37) [16]

Anatoly Podgoretsky © (22.10.03 09:03) [15]
>Да все эти три системы справится, не тот объем и справятся на >порядки с большими размерами и нагрузкой. Тенцера знаешь?
Знаешь конечно. Заочно.

>У него как раз MSSQL и нагрузки по объему, по одновременно >работающим пользователям, по количеству запросов в секунду - >тысячи и никаких жадоб на производительность.
Ну запросы и пользователи разные бывают. Если эти что-то простое как бубен типа биллинга то какие там жалобы. Никаких жалоб не должно быть.
Что у Тенцера не биллинг я знаю и конечно хотел бы посмотреть что у него там вертится но... кто ж покажет.

Кстати, интересно у него тысячи пользователей или параллельных серверных сессий?

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

Имеет ли смысл выбирать IB Найти похожие ветки