Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 24   вперед  Ctrl
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
drev
1. К сожалению, я не могу обсуждать с Вами детали реализации :( могу лишь сказать, что двойное чтение лога есть лишь предположение, а не факт, ок?

Согласен. Пожалуй, правильно будет так: есть факт разницы в скорости при корректно поставленном эксперименте (вроде бы никто не возражал), и есть более-менее правдоподобное предположение, что updated пойдет по "лучшему из графиков", хотя без знания начинки его невозможно подтвердить или опровергнуть.

drev
2. Union all? У Вас в любом из случаев в одной из таблиц будет ноль записей.

И кому станет хуже? Я полагаю правильным рефлекс "писать union all всегда, когда нет явной потребности в подавлении дубликатов"; это ликвидирует несравнимо больше проблем, нежели создается четырьмя дополнительными символами.

drev
3. Вы существенно ошибаетесь в Ваших оценках. Я думаю, через мои руки прошло на пару порядков больше SQL Server кода , чем через Ваши, в силу специфики работы. Я оцениваю вероятность навскидку больше 50%.

Думаю, что Вы поскромничали на порядок-два; мой суммарный mssql-ный опыт вряд ли дотягивает даже до пяти тысяч строк, но вопрос не в этом. Два-три примера реальной потребности в относительно обычных случаях будут куда эффективным аргументом.

Если я соглашусь с Вашей оценкой, я соглашусь и с тем, что удобнее не разделять информацию inserted и updated, и это потребует пересмотреть предлагаемую модель и возможную пользу от нее. Но для согласия - необходимы (не готов сказать, что достаточны) примеры типовых задач, решаемых именно таким образом (как, скажем, я привел типовые остатки и денормализацию).

drev
4. Вам не кажется, что мы пришли к моменту, когда понятно, что тройка inserted, updated, deleted избыточна и, благодаря этому - противоречива?

Нет, не кажется. Как "объективно, само по себе", так и потому, что это утверждение не имеет прямой логической связи с предыдущим, особенно в части противоречивости (избыточна => противоречива, это прямо таки контрольный выстрел в голову денормализации).

drev
T.e. достаточно либо пары inserted, deleted либо одной updated?

"Достаточно" не означает "оптимально или близко к тому". С "достаточно" я согласен, но практичность... спорна.

P.S. Кстати, а нет ли мыслей вот по какому вопросу: если предположить, что "хранить inserted/deleted в памяти для многократной выборки оптимальнее, нежели строить их каждый раз", то зачем вообще лезть за ними в лог, не лучше ли сформировать их сразу во время dml-операции (опять же, проконтролировав потребность в них для триггеров)
18 июл 07, 16:38    [4405349]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
P.S. Кстати, а нет ли мыслей вот по какому вопросу: если предположить, что "хранить inserted/deleted в памяти для многократной выборки оптимальнее, нежели строить их каждый раз", то зачем вообще лезть за ними в лог, не лучше ли сформировать их сразу во время dml-операции (опять же, проконтролировав потребность в них для триггеров)


Я не совсем понял. Вы считаете что они каждый раз формируются при многократном обращении к ним?
18 июл 07, 16:57    [4405517]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
pkarklin
Будет еще как миниум один джоин для выполнения необходимых действий с другой таблицей и, возможно, дополнительное условие фильтрации.

Безусловно. Но это постоянные для всех случаев слагаемые, которые вряд ли стоит учитывать. Хотя... надо подумать, может и есть вариант, когда джойн "целевой таблицы" с "базовой" до deleted будет выгоднее.

pkarklin
Т.е. практически надо сравнивать, что будет быстрее - проход по логу, для формирования inserted и Index Seek по базовой таблице.

Не согласен. Подчеркну в очередной раз: одного прохода по логу достаточно для формирования и inserted, и deleted, и updated, и любого их подмножества. Раз Вы джойните deleted - значит, этот один проход уже есть, и никакого дополнительного "для формирования inserted" плюсовать не нужно. Итого, получается сравнение index seek с нулем, с предсказуемым в общем-то результатом.

Я согласен с тем, что если подтвердится гипотеза о двух проходах в текущей реализации, появится и возможность "оптимальности использования BaseTable" для сегодняшней ситуации. Не уверен, что реально существующая, но по крайней мере теоретическая возможность. Но она не будет аргументом против предлагаемой мной реализации, она будет всего лишь трюком, уместным сегодня и теряющим смысл в моей модели.

pkarklin
Возможно что в этом случаи выигрыш и будет, но о колласальности его можно будет говорить только проведя тестирование.

Под большой таблицей я понимаю ту, которая заведомо лежит в основном на диске. Ее полное сканирование будет заведомо превосходить сканирование лога (даже если тот тоже успел уйти из памяти) в количество раз, примерно равное соотношению размеров читаемых данных, и в абсолютных числах это будут секунды, а то и минуты. Если же лог все еще в памяти - что, учитывая потребность в его сканировании, довольно правдоподобно - то тестирование только покажет, "на сколько именно порядков разница". Я согласен с тем, что измерения - это хорошо, но думаю, качественная оценка может быть дана и так.
18 июл 07, 17:01    [4405566]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
pkarklin
Я не совсем понял. Вы считаете что они каждый раз формируются при многократном обращении к ним?

Я не "считаю", я "учитываю возможность такого варианта". Выше я писал - я склоняюсь к тому, что переиспользование оптимальнее, но уверенности в этом у меня нет; категорического "переиспользуются" ни от кого из знатоков тоже не звучало.
18 июл 07, 17:04    [4405584]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
1. К сожалению, я не могу обсуждать с Вами детали реализации :( могу лишь сказать, что двойное чтение лога есть лишь предположение, а не факт, ок?

Согласен. Пожалуй, правильно будет так: есть факт разницы в скорости при корректно поставленном эксперименте (вроде бы никто не возражал), и есть более-менее правдоподобное предположение, что updated пойдет по "лучшему из графиков", хотя без знания начинки его невозможно подтвердить или опровергнуть.

drev
2. Union all? У Вас в любом из случаев в одной из таблиц будет ноль записей.

И кому станет хуже? Я полагаю правильным рефлекс "писать union all всегда, когда нет явной потребности в подавлении дубликатов"; это ликвидирует несравнимо больше проблем, нежели создается четырьмя дополнительными символами.

drev
3. Вы существенно ошибаетесь в Ваших оценках. Я думаю, через мои руки прошло на пару порядков больше SQL Server кода , чем через Ваши, в силу специфики работы. Я оцениваю вероятность навскидку больше 50%.

Думаю, что Вы поскромничали на порядок-два; мой суммарный mssql-ный опыт вряд ли дотягивает даже до пяти тысяч строк, но вопрос не в этом. Два-три примера реальной потребности в относительно обычных случаях будут куда эффективным аргументом.

Если я соглашусь с Вашей оценкой, я соглашусь и с тем, что удобнее не разделять информацию inserted и updated, и это потребует пересмотреть предлагаемую модель и возможную пользу от нее. Но для согласия - необходимы (не готов сказать, что достаточны) примеры типовых задач, решаемых именно таким образом (как, скажем, я привел типовые остатки и денормализацию).

drev
4. Вам не кажется, что мы пришли к моменту, когда понятно, что тройка inserted, updated, deleted избыточна и, благодаря этому - противоречива?

Нет, не кажется. Как "объективно, само по себе", так и потому, что это утверждение не имеет прямой логической связи с предыдущим, особенно в части противоречивости (избыточна => противоречива, это прямо таки контрольный выстрел в голову денормализации).

drev
T.e. достаточно либо пары inserted, deleted либо одной updated?

"Достаточно" не означает "оптимально или близко к тому". С "достаточно" я согласен, но практичность... спорна.

P.S. Кстати, а нет ли мыслей вот по какому вопросу: если предположить, что "хранить inserted/deleted в памяти для многократной выборки оптимальнее, нежели строить их каждый раз", то зачем вообще лезть за ними в лог, не лучше ли сформировать их сразу во время dml-операции (опять же, проконтролировав потребность в них для триггеров)



IF OBJECT_ID ('Purchasing.LowCredit','TR') IS NOT NULL
   DROP TRIGGER Purchasing.LowCredit
GO
CREATE TRIGGER LowCredit ON Purchasing.PurchaseOrderHeader
AFTER INSERT, UPDATE
AS
DECLARE @creditrating tinyint,
   @vendorid int,
   @total money

SELECT @creditrating = v.CreditRating, @vendorid = p.VendorID, @total = i.total
FROM Purchasing.PurchaseOrderHeader p INNER JOIN inserted i ON p.PurchaseOrderID =
   i.PurchaseOrderID JOIN Purchasing.Vendor v on v.VendorID = i.VendorID

IF @creditrating = 5 AND @total > 1000
BEGIN
   RAISERROR ('This vendor''s credit rating is too low to accept such
      purchase orders.', 16, 1)
ROLLBACK TRANSACTION
END


автор
Because CHECK constraints can reference only the columns on which the column-level or table-level constraint is defined, any cross-table constraints (in this case, business rules) must be defined as triggers
.
18 июл 07, 17:04    [4405587]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Достаточно сджоинить базовую таблицу с deleted. Таким образом можно вообще исключить ситуацию inserted JOIN deleted в триггере на UPDATE.


Кстати, внезапно пришло в голову. Если в update меняется PK (понимаю что за это надо стрелять, но все таки). Что с чем джойнить будем ? И самое главное, ПО ЧЕМУ ???
18 июл 07, 17:15    [4405663]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
softwarer
Скажем, inserted union all updated. Мне кажется, я еще в самом начале писал, что выбор между "почти всегда писать inserted join updated" и "крайне редко писать inserted union all updated".


к тому же union all менее затратный :)
18 июл 07, 17:17    [4405678]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
pkarklin
Достаточно сджоинить базовую таблицу с deleted. Таким образом можно вообще исключить ситуацию inserted JOIN deleted в триггере на UPDATE.


Кстати, внезапно пришло в голову. Если в update меняется PK (понимаю что за это надо стрелять, но все таки). Что с чем джойнить будем ? И самое главное, ПО ЧЕМУ ???


Скрывать не буду. Для MS SQL изменение PK и попытка сравнить inserted и deleted в триггере - нерешаемая задача (в отсутствии альтернативного ключа), ибо отсутствует, доступный разработчик другой уникальный идентификатор строки.
18 июл 07, 17:20    [4405707]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Gluk (Kazan)
pkarklin
Достаточно сджоинить базовую таблицу с deleted. Таким образом можно вообще исключить ситуацию inserted JOIN deleted в триггере на UPDATE.


Кстати, внезапно пришло в голову. Если в update меняется PK (понимаю что за это надо стрелять, но все таки). Что с чем джойнить будем ? И самое главное, ПО ЧЕМУ ???


Скрывать не буду. Для MS SQL изменение PK и попытка сравнить inserted и deleted в триггере - нерешаемая задача (в отсутствии альтернативного ключа), ибо отсутствует, доступный разработчик другой уникальный идентификатор строки.


а сервер это может сделать без особого труда и за одно сканирование :)
18 июл 07, 17:23    [4405727]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
а сервер это может сделать без особого труда и за одно сканирование :)


Безусловно. Эта проблема уже не раз поднималась - отсутсвие, точнее недоступность для разработчика, уникального идентификатора строки. Могу предположить, что это связано с внутренней механикой (точнее с различием в ее реализации) идентфикации строки для кучи или таблицы с некластерным индексом и таблицы с кластерным индексом. :(
18 июл 07, 17:28    [4405764]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
pkarklin
Gluk (Kazan)
pkarklin
Достаточно сджоинить базовую таблицу с deleted. Таким образом можно вообще исключить ситуацию inserted JOIN deleted в триггере на UPDATE.


Кстати, внезапно пришло в голову. Если в update меняется PK (понимаю что за это надо стрелять, но все таки). Что с чем джойнить будем ? И самое главное, ПО ЧЕМУ ???


Скрывать не буду. Для MS SQL изменение PK и попытка сравнить inserted и deleted в триггере - нерешаемая задача (в отсутствии альтернативного ключа), ибо отсутствует, доступный разработчик другой уникальный идентификатор строки.


а сервер это может сделать без особого труда и за одно сканирование :)


К сожалению, это не факт :( Если update был не In-place..
18 июл 07, 17:33    [4405811]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
drev

Хмм....

1. Я понимаю, что это наглость с моей стороны, но уверены ли Вы, что этот триггер написан верно? У меня такое ощущение, что при нескольких строках в inserted он проверит только одну из них, вероятно последнюю. Про "автоцикл" в таком случае как-то не слышал :(

2. Готов зачесть как пример, но крайне искусственный. "Нельзя сделать расходник на тысячу, но можно сделать сотню расходников на сто каждый" - таких бизнес-правил, мягко говоря, поискать.

3. По сути развитие этой идеи - "От записи нужно только id, а дальше будет длинная независимая обработка, например вызов процедуры проверки"... согласен, есть определенная потребность в таких решениях. До 50% не дотягивает порядка-двух, но начало положено.
18 июл 07, 17:33    [4405812]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
drev
К сожалению, это не факт :( Если update был не In-place..

Факт. Я не очень понимаю слова in-place, но факт сугубо медицинский. У сервера есть "реальный адрес записи", поэтому эдакий внутренний join он может сделать в любом случае. А учитывая, что выборки inserted и deleted наверняка синхронно отсортированы - например, в порядке расположения строк на диске, или еще как-нибудь, но внутренняя логика есть наверняка - этот join будет максимально эффективным.
18 июл 07, 17:38    [4405838]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
MGR
Member

Откуда:
Сообщений: 536
softwarer

1. Я понимаю, что это наглость с моей стороны, но уверены ли Вы, что этот триггер написан верно? У меня такое ощущение, что при нескольких строках в inserted он проверит только одну из них, вероятно последнюю. Про "автоцикл" в таком случае как-то не слышал :(


Позволю себе вмешаться.
Но судя по всему, вставляется ЗАГОЛОВОК заказа на покупку.
Не знаю, как в других системах, но в тех, что я знаю - нигде нельзя одновременно вставить больше одной записи в подобную таблицу.
18 июл 07, 17:42    [4405858]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev

Хмм....

1. Я понимаю, что это наглость с моей стороны, но уверены ли Вы, что этот триггер написан верно? У меня такое ощущение, что при нескольких строках в inserted он проверит только одну из них, вероятно последнюю. Про "автоцикл" в таком случае как-то не слышал :(

2. Готов зачесть как пример, но крайне искусственный. "Нельзя сделать расходник на тысячу, но можно сделать сотню расходников на сто каждый" - таких бизнес-правил, мягко говоря, поискать.

3. По сути развитие этой идеи - "От записи нужно только id, а дальше будет длинная независимая обработка, например вызов процедуры проверки"... согласен, есть определенная потребность в таких решениях. До 50% не дотягивает порядка-двух, но начало положено.



Это практически цитата из BOL :)

2. Любая нотификация, типа effective immediately новые цены на следующие товары установлены следующим образом .. хоть мылом, хоть прямо в кассовые аппараты, т.е. любой случай, когда нам интересно только текущее значение
18 июл 07, 17:45    [4405886]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
К сожалению, это не факт :( Если update был не In-place..

Факт. Я не очень понимаю слова in-place, но факт сугубо медицинский. У сервера есть "реальный адрес записи", поэтому эдакий внутренний join он может сделать в любом случае. А учитывая, что выборки inserted и deleted наверняка синхронно отсортированы - например, в порядке расположения строк на диске, или еще как-нибудь, но внутренняя логика есть наверняка - этот join будет максимально эффективным.


In-place - координаты записи не меняются

В другом варианте новые будут отличатся
18 июл 07, 17:55    [4405965]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
softwarer
drev
К сожалению, это не факт :( Если update был не In-place..

Факт. Я не очень понимаю слова in-place, но факт сугубо медицинский. У сервера есть "реальный адрес записи", поэтому эдакий внутренний join он может сделать в любом случае. А учитывая, что выборки inserted и deleted наверняка синхронно отсортированы - например, в порядке расположения строк на диске, или еще как-нибудь, но внутренняя логика есть наверняка - этот join будет максимально эффективным.


In-place - координаты записи не меняются

В другом варианте новые будут отличатся


ага и сервер не будет их знать
18 июл 07, 17:55    [4405971]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
drev
softwarer
drev
К сожалению, это не факт :( Если update был не In-place..

Факт. Я не очень понимаю слова in-place, но факт сугубо медицинский. У сервера есть "реальный адрес записи", поэтому эдакий внутренний join он может сделать в любом случае. А учитывая, что выборки inserted и deleted наверняка синхронно отсортированы - например, в порядке расположения строк на диске, или еще как-нибудь, но внутренняя логика есть наверняка - этот join будет максимально эффективным.


In-place - координаты записи не меняются

В другом варианте новые будут отличатся


ага и сервер не будет их знать



может и не будет:) посмотрите второй пример лога - и найдите их там:)
18 июл 07, 18:04    [4406032]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
Gluk (Kazan)
drev
softwarer
drev
К сожалению, это не факт :( Если update был не In-place..

Факт. Я не очень понимаю слова in-place, но факт сугубо медицинский. У сервера есть "реальный адрес записи", поэтому эдакий внутренний join он может сделать в любом случае. А учитывая, что выборки inserted и deleted наверняка синхронно отсортированы - например, в порядке расположения строк на диске, или еще как-нибудь, но внутренняя логика есть наверняка - этот join будет максимально эффективным.


In-place - координаты записи не меняются

В другом варианте новые будут отличатся


ага и сервер не будет их знать



может и не будет:) посмотрите второй пример лога - и найдите их там:)


ага, и запомнить он их не может :)

P.S. я же не сервер
18 июл 07, 18:08    [4406060]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
MGR
Но судя по всему, вставляется ЗАГОЛОВОК заказа на покупку.
Не знаю, как в других системах, но в тех, что я знаю - нигде нельзя одновременно вставить больше одной записи в подобную таблицу.

Cогласитесь, что техническая возможность сделать это существует, и триггер обязан либо блокировать такие операции, либо обрабатывать и их тоже. На месте злоумышленника я бы очень порадовался возможности "вставить две записи, потом одну удалить" и таким образом обойти проверку.
18 июл 07, 18:10    [4406075]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
P.S. я же не сервер


И это хорошо:) иначе бы он глючил:) или глюкал:)
18 июл 07, 18:12    [4406091]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
MGR
Member

Откуда:
Сообщений: 536
softwarer

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


Триггер обязан, как вы правильно заметили раньше, также обрабатывать ситуацию "10 раз по 100".
Это лишь пример, как я понял.
18 июл 07, 18:16    [4406117]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
Gluk (Kazan)
P.S. я же не сервер


И это хорошо:) иначе бы он глючил:) или глюкал:)


давайте НЕ БУДЕМ переходить к обсуждению НИКОВ ???
18 июл 07, 18:17    [4406125]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
drev
2. Любая нотификация, типа effective immediately новые цены на следующие товары установлены следующим образом

Нуждается в сравнении old с new дабы проверить, что цены действительно изменились. Цитата-цитатой, но не проходит :(

drev
хоть мылом, хоть прямо в кассовые аппараты,

Вот это точно никуда не годится. Триггер сработал, транзакция продолжается, далее почему-то делается rollback - а письма-то уже ушли, чеки-то уже пробиты...
18 июл 07, 18:19    [4406145]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
MGR
Триггер обязан, как вы правильно заметили раньше, также обрабатывать ситуацию "10 раз по 100". Это лишь пример, как я понял.

Признаться, не думаю, что Игорь набивал такую кучу кода вместо того, чтобы сказать несколько слов. Полагаю, он как раз вырезал кусок кода, который был под рукой - иначе не беспокоился бы.
18 июл 07, 18:21    [4406160]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить