Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 26 27 28 29 30 [31] 32 33 34 35 .. 75   вперед  Ctrl
 Re: Выбор СУБД!  [new]
Tapac
Member

Откуда: Альметьевск
Сообщений: 100
Fox5631
Tapac,
ты подтверждаешь то, что я написал несколько страниц назад. Ты не читал весь топик.


Читал, но возможно что-то упустил.
Цитируйте и укажите страницу.
2 фев 09, 21:51    [6769420]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
МСУ

Что такое темплейты процедур? Очередной плод Вашей фантазии?

Темплейт - шаблон.
т.е. "вот так мы пишем процедуры чтобы рулить транзакциями" (вроде вышеприведенного
begin
 ....
 commit;
exception
 when others then 
  rollback;
  raise;
end;
- т.е. в случае успеха - коммит, в случае ошибки - rollback (по хорошему - до savepoint).

но теперь для случая, когда такой блок является процедурой, и внутри которой в свою очередь могут вызываться такие же процедуры, каждая из которых отдает управление транзакциями на откуп тому блоку, который является "верхним".
В принципе, можно что-то соорудить на основе того, что написал softwarer - но мне не интересно придумывать самому, мне интересно - как поступают люди, "изначально писавшие на оракле". Т.е. - "как там принято поступать".
2 фев 09, 21:52    [6769424]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Tapac
Fox5631
Tapac,
ты подтверждаешь то, что я написал несколько страниц назад. Ты не читал весь топик.


Читал, но возможно что-то упустил.
Цитируйте и укажите страницу.


Ну, поищите.
2 фев 09, 21:53    [6769425]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Подпольщик
Guest
В PostgreSQL 2 основных режима транзакций: автокоммит и явное объявление.
При автокоммите всё, что выполняется в теле процедуры есть транзакция.
И явные объявления транзакций, ну тут всё также как в оракле, но без вложенных транзакций.
Внутри транзакций могут быть любые операции, кроме создания\удаления базы\tablespace.
2 фев 09, 21:54    [6769429]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
locky
когда такой блок является процедурой, и внутри которой в свою очередь могут вызываться такие же процедуры, каждая из которых отдает управление транзакциями на откуп тому блоку, который является "верхним".

Правильно, Локи. Идете верным путем :)

locky
В принципе, можно что-то соорудить на основе того, что написал softwarer - но мне не интересно придумывать самому, мне интересно - как поступают люди, "изначально писавшие на оракле". Т.е. - "как там принято поступать".

Как часто Вы встречаетесь с подобной задачей? :)
2 фев 09, 21:56    [6769434]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Fox5631
МСУ,
ты у меня напросишься.


Опять угрожаете, бать? )
2 фев 09, 21:57    [6769435]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
locky
Довольно таки актуальный, если подумать.

"Актуальность" определяется вовсе не "подуманием". Актуальность определяется толпами разработчиков, страдающих вопросом "ну когда же наконец и у нас появится такая хорошая фича?"

locky
но это, согласитесь, несколько некошерно

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

locky
Хотя, судя по тому, что я о нём не сильно слышал - на практике такое встречается очччень редко.

Что объективно доказывает неактуальность. Используется она... ну вот например PL/SQL Developer использует, чтобы управлять свойством enabled у кнопки Commit.
2 фев 09, 21:57    [6769436]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Tapac
Member

Откуда: Альметьевск
Сообщений: 100
проходящий.
Tapac
Из FoxPro тестируем поиск в dbf:
SET SAFETY OFF
SET TALK OFF

CLEAR ALL
USE C:\test.dbf
n = 100

s0 = SECONDS()
FOR i=1 TO n
	SELECT ID FROM test WHERE data = "test text" INTO CURSOR tmp
ENDFOR
s = SECONDS()

? 'Общее время выполнения:' + LTRIM(STR(s-s0,7,5))
? 'Среднее время поиска:' + LTRIM(STR((s-s0)/n,7,5))

Из FoxPro тестируем поиск в Oracle:
[src]
SET SAFETY OFF
SET TALK OFF

n = 100
nh = SQLCONNECT( "test", "test", "test")
SQLPREPARE( nh, "SELECT ID FROM test WHERE data='test text'")

s0 = SECONDS()
FOR i=1 TO n
SQLEXEC(nh)
ENDFOR
s = SECONDS()

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


SQLEXEC() внутри цикла загружает результаты запроса "SELECT ID FROM test WHERE data='test text'", полученные Oracle, и через ODBC загружает в локальный курсор FoxPro с именем (по-умолчанию) Sqlresult.

Не знаю в FoxPro команд предварительного построения и сохранения планов запросов. Укажите -- поправим тест.
2 фев 09, 22:02    [6769448]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
МСУ
Как часто Вы встречаетесь с подобной задачей? :)

Постоянно.
При построении приложения из "кубиков".
2 фев 09, 22:05    [6769459]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
softwarer

Что объективно доказывает неактуальность. Используется она... ну вот например PL/SQL Developer использует, чтобы управлять свойством enabled у кнопки Commit.

А я, кстати, думал еще - ведь девелопер как-то ж определяет - нужно, не нужно....
2 фев 09, 22:06    [6769461]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
softwarer
Нормальных прикладных задач, где без LTT приходится извращаться, я пожалуй сходу даже и не вспомню.

Всегда можно обойтись коллекциями (пакетными)? ;)
2 фев 09, 22:07    [6769464]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Fox5631
У тебя хорошо получалось держать дистанцию.

Бабуль, может, мириться настало время? )

locky
МСУ
Как часто Вы встречаетесь с подобной задачей? :)

Постоянно.
При построении приложения из "кубиков".

Для приложения пробовали не кубики строить средствами лисапедирования, а использовать полноценную ORM?
2 фев 09, 22:07    [6769466]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Кстати, народ - что слышно по поводу пэкэджей в сиквеле? :) Хочется тоже такую рюшечку :)
2 фев 09, 22:09    [6769470]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
locky
Всегда можно обойтись коллекциями (пакетными)? ;)

Вовсе не в кассу. У коллекций столь же статичная структура, "создание структуры на лету" ими решается ничуть не лучше. Но вот задачи, где LTT явно нужна именно в таком виде.... по-прежнему в густом тумане.
2 фев 09, 22:22    [6769502]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Tapac
Member

Откуда: Альметьевск
Сообщений: 100
Fox5631
Я привел ссылку на статью, в которой написано, при каком объеме базы данных нужно переходить на сервер. И именно из-за замедления работы. Поскольку в реальной базе используются более сложные вопросы.
На средней БД Fox выигрывает в скорости.


Хм, предложенный "лобовой" тест показал, что разница по поиску составляет 0.00002 сек. Это, конечно, "выигрыш" FoxPro для "небольшого" объема 1 млн.записей.
Можно, конечно, сделать тесты и по-любопытнее (данный топик уже породил массу интересных заданий для нашей молодежи из выпускников), но Fox5631, существует крайне мало личностей, способных публично признать свои ошибки, особенно, после их публичного совершения.
В конечном счете, задуматься (без свидетелей) Вам с Евгением важнее, чем бОльшей части данной аудитории. Удачи (без иронии).

P.S. Объем данных -- не единственный и не главный аргумент для перехода на сервер БД.
2 фев 09, 22:34    [6769535]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
Fox5631
На средней БД Fox выигрывает в скорости.
Это на 40 таблиц, 150 Mb и десяток юзеров?...
Ну просто никак не получается объяснить Вам, насколько это Пиррова победа (хотя выигрыш в скорости не доказан, но пусть их).
Ну представьте, что Вы купили машину, в которой разработчики не предусмотрели педаль тормоза, и радуетесь, что она несется на поворотах быстрее всех!...
У адептов ФоксПро есть чувство самосохранения?...
2 фев 09, 22:45    [6769559]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
Dimitry Sibiryakov

Eugenkru1
я тебе объясню как сделать склад.

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

Это не так сложно. Сейчас объясню.
Всем, кто хоть раз в жизни писал склад, известна, конечно, такая технлогия, как "закрыть период по текущее время". То есть мы по сети предупреждаем пользователей, что готовится отчет, и редактирование накладных может быть не проведено, или проведено частично. Ждем 2-3 минуты, и закрываем период до текущего. Формируем отчет и снимаем закрытие. После этого, пользователи могут "допровести" свои документы задним числом в реальном времени.
Кроме того мы, естесственно используем механизм "инвентаризация", это когда реально надо пересчитать остатки. Ну, говоря вашим языком, это как если коммитится большая многомесячная транзакция, и остатки пересчитываются по всем контрольным точкам, начиная с начала работы БД. Понятно, что эту процедуру лучше запускать вечером, когда пользователи уже не работают с базой, тогда к утру мы имеем совершенно выверенную информацию, которую передаем кладовщикам, и они сверяют по ней фактическое наличие товара.
2 фев 09, 23:09    [6769610]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
softwarer
locky
Всегда можно обойтись коллекциями (пакетными)? ;)

Вовсе не в кассу. У коллекций столь же статичная структура, "создание структуры на лету" ими решается ничуть не лучше. Но вот задачи, где LTT явно нужна именно в таком виде.... по-прежнему в густом тумане.

Ну, если мы будем разговаривать о DDL "под заказ" (динамическое добавление полей етк), то для оракла разговор закончится чуть раньше, чем начнётся, не так ли?
А вот иметь возможность внутри процедуры обьявить временное хранилище нужной структуры для промежуточных результатов - это весьма пользительно.
Или тут еще есть апологеты, которые искренне считают, что "все задачи можно выполнить одним запросом"?
2 фев 09, 23:51    [6769752]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
Пупукин
К коммиты или роллбэки в пакетах и процедурах допустимы только в тех
случаях, где управление транзакцией со стороны клиента или не возможно в принципе, или..
не возможно в принципе.
То есть допустимы всегда?... :)
3 фев 09, 00:07    [6769787]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
МСУ
Для приложения пробовали не кубики строить средствами лисапедирования, а использовать полноценную ORM?

На кой, простите, хрен?
И что есть ORM?
Маппинг объектов на базу?
3 фев 09, 00:36    [6769850]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
народ, а почему я вижу комментарии (цитаты) на некоторые сообщения, но самих сообщений не вижу? Глючит форум? Или сообщения Eugenkru1 удаляются автоматически, или кто-то их удаляет?

Eugenkru1
Меняем выражение с целью найти больше записей
SELECT Фамилия from фамилии WHERE Фамилия='_2KK2S86M' INTO CURSOR результат
Время выполнения запроса составляет 0,09 секунды!

ты туп до безобразия. там где b-tree, результат такого поиска ВСЕГДА будет ОДИН И ТОТ ЖЕ. То есть на любом сервере это БУДЕТ БЫСТРО.

автор
Rushmore...

http://www.foxpert.com/docs/howfoxproworks.en.htm
я уже давно давал комментарий:
использовать этот рашмор можно только на "плоских" таблицах. т.е. где в одном файле только один тип записи, и записи имеют фиксированный размер. Т.к. индекс это битовая маска, с признаком 1 или 0 для конкретного физического НОМЕРА записи, исчисляемого от начала файла.
Если вникнуть в суть b-tree, понимать страничные индексы и т.д., то пресловутый Rushmore не представляет никакого "откровения". Более того, см. статью по ссылке, в ряде случаев он замедляет выборку.

А битовое слияние результатов поиска по индексу не секрет, оно еще в древних версиях InterBase (конец 80-ых) применялось и применяется сейчас в IB/FB. И в других серверах битовые индексы также давно поддерживаются.
Так что этот Rushmore был ничем не более маркетингового лозунга.
3 фев 09, 00:36    [6769851]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
locky
МСУ
Для приложения пробовали не кубики строить средствами лисапедирования, а использовать полноценную ORM?

На кой, простите, хрен?
И что есть ORM?
Маппинг объектов на базу?

Да, он самый. На кой??? Батенька, почитайте про идеологию Linq to SQL, Entity Framework, NHibernate. Придет озарение, уверяю Вас.
3 фев 09, 00:48    [6769864]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31621
kdv

использовать этот рашмор можно только на "плоских" таблицах. т.е. где в одном файле только один тип записи, и записи имеют фиксированный размер. Т.к. индекс это битовая маска, с признаком 1 или 0 для конкретного физического НОМЕРА записи, исчисляемого от начала файла.

Можно использовать и в случае переменной длины записи (c промежуточной структурой данных, например, ассоциатора ADABAS)
3 фев 09, 00:50    [6769866]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
МСУ
Да, он самый. На кой??? Батенька, почитайте про идеологию Linq to SQL, Entity Framework, NHibernate. Придет озарение, уверяю Вас.

Это когда "очень удобно реализовывать обработку данных на стороне клиента/промежуточного звена"?
И, позвольте мне спросить - накуя я должен хранить данные отдельно, а обрабатывать их - отдельно?
М.б. лучше сразу к фоксу возвернутся?
Любой промслой, любая допбиблиотека, "маппинг" БД на что угодно - это "Тормоз++".
Я, конечно, понимаю - железо нынче дёшево, а технологий, наоборот - очень много, и всё хочется попробовать. Но я решительно не понимаю - зачем необходимо умножать сущности.
3 фев 09, 00:52    [6769867]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
locky
Ну, если мы будем разговаривать о DDL "под заказ" (динамическое добавление полей етк), то для оракла разговор закончится чуть раньше, чем начнётся, не так ли?

Не так ли, конечно.

locky
А вот иметь возможность внутри процедуры обьявить временное хранилище нужной структуры для промежуточных результатов - это весьма пользительно.

Вот как раз внутри процедуры такому объявлению делать совершенно нечего. Процедура - это место для описания логики. Объявления раздувают её и усложняют восприятие.

locky
Или тут еще есть апологеты, которые искренне считают, что "все задачи можно выполнить одним запросом"?

В общем, примера пользы LTT так и не приведено, только пара лозунгов
3 фев 09, 01:36    [6769912]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 26 27 28 29 30 [31] 32 33 34 35 .. 75   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить