Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 62 63 64 65 66 [67] 68 69 70 71 .. 75   вперед  Ctrl
 Re: Выбор СУБД!  [new]
Fox5631
Guest
По поводу многозвенки зайдите на Фоксклуб. Если вас действительно это интересует, поищите там или задайте вопрос.
По второму вопросу - я нигде не говорил, что FoxPro надежней, чем сервера.
Я лишь сказал, что ни то, ни другое не обеспечивает 100% сохранности данных, несмотря на все дополнительные возможности серверов.
Потери данных возможны и там, и там.
Сервер обеспечивает большую надежность.
Но это не значит, что по этой причине всегда нужно выбирать сервер.

Работают сотни тысяч приложений без использования серверов и никаких потерь данных там тоже нет.
6 фев 09, 12:04    [6787647]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
locky
Sgt.Pepper
если без малопонятных аналогий - декларативности - свое место?.. она не всегда облегчает разработку?... Лучше оделить мух от котлет и в 90% случаев писать циклы?...

так, видимо, будет более-менее правильно.

И, главное, аргументированно :)
Зачеркните, плиз, лишние символы в таком утверждении и поставим на этом точку.
Львиная доля обработки данных в БД происходит через хранимые процедуры. В Oracle для этого используется синтаксис с бесконечными "for .. loop" с гарантией получить exception, если select возвращает больше, чем одну запись. И это правильно, потому как в хранимых процедурах лучше держаться подальше от классического sql
6 фев 09, 12:22    [6787780]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sgt.Pepper
В Oracle для этого используется синтаксис с бесконечными "for .. loop" с гарантией получить exception, если select возвращает больше, чем одну запись. И это правильно, потому как в хранимых процедурах лучше держаться подальше от классического sql


IMHO забыл поставить
6 фев 09, 12:25    [6787798]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
Gluk (Kazan)
Sgt.Pepper
В Oracle для этого используется синтаксис с бесконечными "for .. loop" с гарантией получить exception, если select возвращает больше, чем одну запись. И это правильно, потому как в хранимых процедурах лучше держаться подальше от классического sql


IMHO забыл поставить

Нет, это не ИМХО, это то, как я понял позицию Локи и Софварера. И просто хочу услышать ее подтверждение или опревержения.
6 фев 09, 12:30    [6787839]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
СофТварера (Sowtwarer'а), извиняюсь...
6 фев 09, 12:40    [6787892]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
Да что ж такое-то!..
Работа над ошибками: Softwarer Softwarer Softwarer
6 фев 09, 12:42    [6787911]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Sgt.Pepper
В Oracle для этого используется синтаксис с бесконечными "for .. loop" с гарантией получить exception, если select возвращает больше, чем одну запись. И это правильно, потому как в хранимых процедурах лучше держаться подальше от классического sql

Можно и без бесконечных for loop.
Очень часто бездумное использование курсов появляется в результате... бездумного использования курсоров. Строго по книге, раздел "Коллекции, курсоры, применения".
6 фев 09, 12:49    [6787955]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Sgt.Pepper
Нет, это не ИМХО, это то, как я понял позицию Локи и Софварера. И просто хочу услышать ее подтверждение или опревержения.

Насколько я понимаю, моя позиция состоит в том, чтобы забивать гвоздит молотком, а гайки закручивать гаечным ключом.
Хотя, безусловно, нормальным гаечным ключом можно более-менее нормально забить гвоздь, а гайку открутить плоскогубцами.
6 фев 09, 12:51    [6787966]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Fox5631
По поводу многозвенки зайдите на Фоксклуб. Если вас действительно это интересует, поищите там или задайте вопрос.
По второму вопросу - я нигде не говорил, что FoxPro надежней, чем сервера.
Я лишь сказал, что ни то, ни другое не обеспечивает 100% сохранности данных, несмотря на все дополнительные возможности серверов.
Потери данных возможны и там, и там.
Сервер обеспечивает большую надежность.
Но это не значит, что по этой причине всегда нужно выбирать сервер.

Работают сотни тысяч приложений без использования серверов и никаких потерь данных там тоже нет.

На форексклуб заходить - это означало бы уделять неоправданное внимание устаревшим технологиям. Зачем када есть кое-что посовременнее? Ведь не желательно же тратить время на технологии повышенного риска в плане их отмирания?
Луче Вы переходите на более современные технологии. И дело даже не просто в СУБД.
Например, в решениях Оракла используются и Беркли для портативных устройств и Times Ten для БД in memory и сможет просто в качестве хешировать в связке с осеновной Оракле БД. Да и СУБД Оракле может поддерживать уже и длинные тразакции. И МД не тока реляционные, объектно реляционные, но вчера на конференции узнал, что и сетевые (графовые), полуструктрированные (XML). Там всякие неструтурированные типы данных (мультимедиа), тектовые.
И тулсы шобы быстро лабать простые приложения да и не простые. Да и диалект SQL возьмите. Например, аналитические ф-ии. Я вот счас на второй работе делаю отчет. Там БД Аксцесс. Но там полно запросов по провеке и поиску отклонений данных (они из разных отделов и плохосогласованные и с ошибками, а за ошибки могут быть штрафы реальные). Диалект SQL Аксцесса не позволяет быстро лабать для сложных случаев, а то и вообще приходилось VBA подключать. Я подцепил к Аксцеесу Оракла и на многие вопросы получаю легко в плане написания запросов ответ.
Поди плохо?
6 фев 09, 12:56    [6788018]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
locky
Sgt.Pepper
Нет, это не ИМХО, это то, как я понял позицию Локи и Софварера. И просто хочу услышать ее подтверждение или опревержения.

Насколько я понимаю, моя позиция состоит в том, чтобы забивать гвоздит молотком, а гайки закручивать гаечным ключом.
Хотя, безусловно, нормальным гаечным ключом можно более-менее нормально забить гвоздь, а гайку открутить плоскогубцами.
Иногда аллегории что-то удачно иллюстрируют, часто просто наводят тумана.
Разговор начался с того, что tsql в хранимых процедурах синтаксически ближе к ansi sql, чем pl/sql. Выглядит так, что там больше "декларативности и множеств" :)
Я понимаю, что всему свое место и время, но Вы согласитесь со мной, что "среднестатистический программист" на pl/sql на порядок чаще использует курсоры и циклы, нежели "среднестатистический программист" на tsql (если не так - поправьте меня)
Мне говорят - ну и что, здесь же процедуры, чем больше императива, тем лучше.
Не так?..
6 фев 09, 13:16    [6788156]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Sgt.Pepper
Разговор начался с того, что tsql в хранимых процедурах синтаксически ближе к ansi sql, чем pl/sql. Выглядит так, что там больше "декларативности и множеств" :)
Я понимаю, что всему свое место и время, но Вы согласитесь со мной, что "среднестатистический программист" на pl/sql на порядок чаще использует курсоры и циклы, нежели "среднестатистический программист" на tsql (если не так - поправьте меня)
Мне говорят - ну и что, здесь же процедуры, чем больше императива, тем лучше.
Не так?..

Начнем с того, что среднестатистический программист на t-sql значительно реже использует record, нежелт человек, использующий pl/sql.
Продолжим тем, что, если бы на t-sql работать с циклами и курсорами было бы так же удобно, как и в pl/sql, то, пмсм, мы были бы несчастливыми свидетелями того, что и в t-sql очень широко применяются циклы и курсоры.
6 фев 09, 13:19    [6788180]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Ах да! И не стоит забывать о rowid - весьма удобная для цикла/курсора вещь.

-------------------------
There’s no silver bullet!
6 фев 09, 13:22    [6788198]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
locky
Начнем с того, что среднестатистический программист на t-sql значительно реже использует record, нежелт человек, использующий pl/sql.
Продолжим тем, что, если бы на t-sql работать с циклами и курсорами было бы так же удобно, как и в pl/sql, то, пмсм, мы были бы несчастливыми свидетелями того, что и в t-sql очень широко применяются циклы и курсоры.

Но "несчастливыми свидетелями" - это без иронии?.. т.е. ничего хорошего в стремлении к этому нет?..
6 фев 09, 13:22    [6788199]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
Gluk (Kazan)

Неа, не получается, во вложении схема по констрейнтам, не вижу:

буду рад примеру DML, который к одному value привяжет более одного settings.


insert into type(id) values(1);
insert into type(id) values(2);

insert into value(element,parametr) values (1, 3); -- Адын

insert into element(id, type) values (1, 1);
insert into element(id, type) values (2, 1); -- Хулиганство
insert into element(id, type) values (3, 2);
insert into element(id, type) values (4, 2); -- Хулиганство

insert into settings(etype, ptype) values (1, 2);
insert into settings(etype, ptype) values (2, 1); -- Засада

Не ладно что-то в королевстве ?
6 фев 09, 13:31    [6788254]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Sgt.Pepper
Но "несчастливыми свидетелями" - это без иронии?.. т.е. ничего хорошего в стремлении к этому нет?..

Нет ничего хорошего в стремлении "булдь що" и "фсегда-фсегда-фсегд" "не взирая ни на что" использовать строго один подхог/технологию/инструмент/етк.
6 фев 09, 13:31    [6788255]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Gluk (Kazan)
locky
Gluk (Kazan)

Неа, не получается, во вложении схема по констрейнтам, не вижу:

буду рад примеру DML, который к одному value привяжет более одного settings.


insert into type(id) values(1);
insert into type(id) values(2);

insert into value(element,parametr) values (1, 3); -- Адын

insert into element(id, type) values (1, 1);
insert into element(id, type) values (2, 1); -- Хулиганство
insert into element(id, type) values (3, 2);
insert into element(id, type) values (4, 2); -- Хулиганство

insert into settings(etype, ptype) values (1, 2);
insert into settings(etype, ptype) values (2, 1); -- Засада

Не ладно что-то в королевстве ?


Values.Element=1->Element.ID=1->Element.Type=1->settings.etype=1
Values.Element=3->Element.ID=3->Element.Type=2->settings.ptype=2
select * from Settings where etype=1 and ptype=2
1 row affected
select * from Value where element = 1 and parameter=3
1 row affected.

Вроде всё хорошо, призрака короля не наблюдаю.
6 фев 09, 13:34    [6788274]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
vadiminfo
На форексклуб заходить - это означало бы уделять неоправданное внимание устаревшим технологиям. Зачем када есть кое-что посовременнее? Ведь не желательно же тратить время на технологии повышенного риска в плане их отмирания?
Поди плохо?


Ну если в .нетовские технологии добавляют обработку данных на клиенте, значит не такие они и устаревшие.
6 фев 09, 13:35    [6788276]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
Gluk (Kazan)
locky
Gluk (Kazan)

Неа, не получается, во вложении схема по констрейнтам, не вижу:

буду рад примеру DML, который к одному value привяжет более одного settings.


insert into type(id) values(1);
insert into type(id) values(2);

insert into value(element,parametr) values (1, 3); -- Адын

insert into element(id, type) values (1, 1);
insert into element(id, type) values (2, 1); -- Хулиганство
insert into element(id, type) values (3, 2);
insert into element(id, type) values (4, 2); -- Хулиганство

insert into settings(etype, ptype) values (1, 2);
insert into settings(etype, ptype) values (2, 1); -- Засада

Не ладно что-то в королевстве ?


Values.Element=1->Element.ID=1->Element.Type=1->settings.etype=1
Values.Element=3->Element.ID=3->Element.Type=2->settings.ptype=2
select * from Settings where etype=1 and ptype=2
1 row affected
select * from Value where element = 1 and parameter=3
1 row affected.

Вроде всё хорошо, призрака короля не наблюдаю.


Ты просил два сеттинга на один валуес ?
6 фев 09, 13:43    [6788323]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Gluk (Kazan)
Ты просил два сеттинга на один валуес ?

Да. Когда ОДНОЙ строке value соответствует более одной строки settings.
т.е. когда в update может "справа" прийти более чем одна запись, и невозможно определить по ключам взаимно однозначное соответствие.
6 фев 09, 14:20    [6788597]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
Sgt.Pepper
Разговор начался с того, что tsql в хранимых процедурах синтаксически ближе к ansi sql, чем pl/sql. Выглядит так, что там больше "декларативности и множеств" :)

Вот этот переход уже не совсем верен. Я бы сказал "выглядит большей кашей из декларативности и императивности".

Sgt.Pepper
но Вы согласитесь со мной, что "среднестатистический программист" на pl/sql на порядок чаще использует курсоры и циклы,

Может быть - не знаю - но это бессмысленная постановка вопроса. Скажем, взял я первый попавшийся пакет из не-своего приложения, и в нём почти все "курсоры и циклы" имеют вид:

    FOR rec IN (SELECT NULL FROM SPS.vw_ACCNT_h t WHERE t.psid IN (SELECT sid FROM TABLE(CAST(SPS.pkg_a_ACCNT.sids AS sps.tpt_sid)) s) AND t.sid <> t.psid) LOOP 
      sps.pkg_errhandle.raise (sps.pkg_errhandle.cannot_delete_base_edition);
    END LOOP;

С моей точки зрения - это ровно ничем не отличается от

    IF EXISTS (SELECT NULL FROM SPS.vw_ACCNT_h t WHERE t.psid IN (SELECT sid FROM TABLE(CAST(SPS.pkg_a_ACCNT.sids AS sps.tpt_sid)) s) AND t.sid <> t.psid) 
      sps.pkg_errhandle.raise (sps.pkg_errhandle.cannot_delete_base_edition);
    

Вы же почему-то утверждаете, что во втором случае "больше декларативности". Я этого не понимаю. А Вы аж теорию развиваете :)
6 фев 09, 14:21    [6788608]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
softwarer
С моей точки зрения - это ровно ничем не отличается от

Формально - цикл может выполнится несколько раз, в случае если запрос вернул более одной строки и нет break;
6 фев 09, 14:25    [6788660]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
locky
softwarer
С моей точки зрения - это ровно ничем не отличается от

Формально - цикл может выполнится несколько раз, в случае если запрос вернул более одной строки и нет break;

Формально, конечно, подпрограмма raise вовсе не обязана выполнять raise...
6 фев 09, 14:31    [6788711]     Ответить | Цитировать Сообщить модератору
 Re: тогда вопрос номер два!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
softwarer
locky
softwarer
С моей точки зрения - это ровно ничем не отличается от

Формально - цикл может выполнится несколько раз, в случае если запрос вернул более одной строки и нет break;

Формально, конечно, подпрограмма raise вовсе не обязана выполнять raise...

Я ж и говорю - "формально".
Потому как отличия в случае таки одной строки, видимо, нету.

Хотя, если придираться, то я бы придрался Но я не знаю, как там оракл "внутре" работает
6 фев 09, 14:37    [6788764]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
Gluk (Kazan)
Ты просил два сеттинга на один валуес ?

Да. Когда ОДНОЙ строке value соответствует более одной строки settings.
т.е. когда в update может "справа" прийти более чем одна запись, и невозможно определить по ключам взаимно однозначное соответствие.


Как я уже сказал, Oracle не способен на умозаключения. Ты связываешься, фактически через таблицу type, но сама она у тебя даже в запросе не фигурирует. В общем жди пока в Oracle встроют ИИ.
Чтобы ускорить этот процесс, можешь пожаловаться в техподдержку.

Oracle ничего не знает о запросах, которые ты собираешься формировать, ибо даром предвидения не обладает, он оперирует ограничениями на БД, которые ты задал, а их явно недостаточно, не знаю как тебе это объяснить, да и утомил меня этот пример слегка
6 фев 09, 14:54    [6788915]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Gluk (Kazan)
Oracle ничего не знает о запросах, которые ты собираешься формировать, ибо даром предвидения не обладает, он оперирует ограничениями на БД, которые ты задал, а их явно недостаточно, не знаю как тебе это объяснить, да и утомил меня этот пример слегка

С моей т.з. - достаточно.
PK на value, PK на сеттинг, транзитное отношение 1-1 в element как бэ намекает нам на то, что settings мапится на value в пропорции 1:1.
Но, увы и ах - "оракл не даст вам выстрелить себе в ногу"
6 фев 09, 15:17    [6789084]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 62 63 64 65 66 [67] 68 69 70 71 .. 75   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить