Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 70 71 72 73 74 [75] 76 77 78 79 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn
Выбегалло>>Умеете ли вы "за наименьшее время" написать алгоритм выборки с использованием хэш-таблиц ?
А что проблемы ? Не нужно считать что М-специалисты ничего за своб жизнь не видели.


ну показывайте.


Ptn
>>А с индексами ?
Какие проблемы ?


показывайте.

Ptn
>>А с фрагментированием по разным дискам для распараллеливания IO?
А по ECP ?


ECP ? Short for Extended Capabilities Port, a parallel-port standard for PCs that supports bi-directional communication between the PC and attached devices (such as a printer). ECP is about 10 times faster than the older Centronics standard.
показывайте.


Ptn
>>А сумеете самостоятельно написать оптимизатор, который будет анализировать предполагаемую стоимость выборки и принимать решение, каким из вариантов пользоваться ?

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


В том то и дело, что "в упрощенном виде". Ну очень упрощенном.

Ptn
>>Блокировки, откаты, разные степени изоляции - легко и просто ?
Читайте доки они рулез


Название доки, номер страницы ?

Ptn
>>Какой процент ваших read-ов лезет на диск за данными, а какой - использует уже имеющиеся в буферах ?
надесь видеть подробное описание как это делать в MS-SQL.


насчет ms sql не знаю, а в информиксе onstat -p все прекрасно показывает :

IBM Informix Dynamic Server Version 9.40.TC2E1 -- On-Line -- Up 00:01:53 -- 25728 Kbytes

Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
39 46 323 87.93 7 7 0 0.00

И самый цимес в том, что ну абсолютно ничего делать не надо - все уже сделано до вас.
7 янв 07, 23:38    [3612462]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
> А использование оперативной памяти - занятие для СУБД.
> Интересует техническая сторона дела : как легко (и можно ли вообще) одну задачу распараллелить на 4 процессора.


Итак дискуссия постепенно подошла к преимуществам М&Cache.
Не уверен, что смогу точно выразить свою мысль, но попробую.

- Сколько СУБД в РСУБД?
Одна. Она крутится на сервере.

- Сколько процессоров крутит РСУБД?
Столько, сколько есть на сервере.

- А сколько на сервере процессоров?
2? 4?
И сколько озу на сервере?
10Г? А может 80Г? О! Это ларджест сервер c 4-мя процессорами! За $40 тыс.

В Cache уже сегодня де-факто 1 базу может именно ПАРАЛЛЕЛЬНО крутить 256 процессоров Sempron на 256 PC с общим озу равным озу на одном PC* количество PC, т.е. если в каждом PC 8Г озу мы получаем фантазийную цифру – 2048Г озу – и это еще не учтен сам сервер.

И из аппаратуры может использоваться процессор Sempron за 30$ и матплата ASRock за 40$ = 70$
70$*256=$17920

4 процессора – за 40 тыс.$ в РСУБД
и 256 процессоров – за 18 тыс.$ в Cache

(отбросим деньги – но какая система будет мощнее?)

«Техническая сторона дела» - «как распараллелить по процессорам» - у М-программиста задача решенная самим Cache.
Видимо это отличает GT.M размеров 2 мегабайта и FreeM размером 800 килобайт от Cache размером 150 мегабайт.

Дело в том, что в M&Cache база умеет «заползать» с сервера в озу М-клиентов и там обрабатываться локально, вообще не паря сервер.

Как «распараллелить» базу РСУБД для меня загадка.
Сейчас конечно кто-то скажет про «кластер», но кто его видел это кластер?
Ну и каков коэффицент «распараллеливания» достигнут?
И что там с дисковой системой этого кластера?

Все это весьма туманно и нетривиально с технической точки зрения.

Мораль такая (меня в любых спорах привлекают именно моральные аспекты) – если вам не нужна мощность – вам М программы не нужны.

Если у вас – полтора юзера – вам М программы не нужны.

М программа – это 1000 запросов юзеров в секунду – поймите это один раз и навсегда.
Там некогда «парсить» SQL.

В соседней ветке один приятель решает задачу – запись данных со скоростью 50000 изменений/секунду
(не знаю может шутка, но он на правильном пути – тут от java-технологий и от селекта лучше отказаться сразу)

Все это придумано не мной, а просто были люди которые выжимали из селекта, выжимали – плюнули на него и перешли на М.

А по мне и Access хорош (для 15 юзеров).
Но обслужить 10 млн. юзеров на нем нельзя.
7 янв 07, 23:54    [3612480]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
2frutalino: вы будете смеяться, но кластерные решения есть даже у MySQL, not to mention Oracle RAC. У MS SQL тоже есть подобное.
8 янв 07, 00:33    [3612519]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
frutalino

Дело в том, что в M&Cache база умеет «заползать» с сервера в озу М-клиентов и там обрабатываться локально, вообще не паря сервер.

Телепатически, полагаю?
frutalino

Как «распараллелить» базу РСУБД для меня загадка.
Сейчас конечно кто-то скажет про «кластер», но кто его видел это кластер?
Ну и каков коэффицент «распараллеливания» достигнут?
И что там с дисковой системой этого кластера?

Все это весьма туманно и нетривиально с технической точки зрения.

То ли дело старая добрая телепатия...
frutalino

Мораль такая (меня в любых спорах привлекают именно моральные аспекты) – если вам не нужна мощность – вам М программы не нужны.

Если у вас – полтора юзера – вам М программы не нужны.

М программа – это 1000 запросов юзеров в секунду – поймите это один раз и навсегда.
Там некогда «парсить» SQL.

Выкидывайте свой М, для 500 запросов в секунду на MySQL даже отдельную машину не выделяют.
frutalino

В соседней ветке один приятель решает задачу – запись данных со скоростью 50000 изменений/секунду
(не знаю может шутка, но он на правильном пути – тут от java-технологий и от селекта лучше отказаться сразу)

Все это придумано не мной, а просто были люди которые выжимали из селекта, выжимали – плюнули на него и перешли на М.
Пакетную запись не судьба использовать, обязательно дёргать сервер 50 тысяч раз в секунду?
8 янв 07, 00:40    [3612526]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
))
Guest
frutalino
М программа – это 1000 запросов юзеров в секунду – поймите это один раз и навсегда.

обратно не понял, погуглил "transactions per second", обнаружилось "A $2k computer can execute about 8k transactions per second". 2005 год, ms sql, здесь :)
и про заползание с сервера в озу клиентов... помедленнее. спасибо )
8 янв 07, 01:01    [3612540]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
V52
Guest
Выбегалло
V52

Отсюда вытекает эффективность использования М. Кто бы что ни говорил, но программу написать – раз плюнуть, если известно, что и как надо писать. Т.е. основная трудоемкость программирования – разработка ОПТИМАЛЬНОГО алгоритма. Абсолютное отсутствие в М ограничений на структуры данных позволяет разрабатывать наиболее оптимальные алгоритмы за наименьшее время. Именно поэтому я являюсь его сторонником.

Да, в исходном М нет SQL и его центральной части – оператора SELECT. Потому что он НЕ НУЖЕН так как М позволяет строить алгоритмы с превалирующим ПРЯМЫМ обращением к данным, а не через механизм последовательной выборки. А для организации последовательной выборки можно организовать один-два цикла с условиями отбора, что по трудоемкости написания не превышает изображение SELECTa.


Кто вам сказал, что для сложных выборок прямой перебор с внутренними циклами - "наиболее оптимальный алгоритм" ? Умеете ли вы "за наименьшее время" написать алгоритм выборки с использованием хэш-таблиц ? А с индексами ? А с read-ahead ? А с фрагментированием по разным дискам для распараллеливания IO? А fragment elimination сделаете ? А сумеете самостоятельно написать оптимизатор, который будет анализировать предполагаемую стоимость выборки и принимать решение, каким из вариантов пользоваться ? А как у вас с написанием, за наименьшее время, поддержки транзакций ? Блокировки, откаты, разные степени изоляции - легко и просто ? за три дня управитесь ? А как насчет кеширования - имеете доступ под капот M, сможете его заставить часто используемые данные хранить в памяти ? Какой процент ваших read-ов лезет на диск за данными, а какой - использует уже имеющиеся в буферах ?

MUMPS - это не СУБД. Это набор "сделай сам".


Уважаемый професор! Практически ничего из перечисленного вами мне делать не приходится. Я говорил об оптимальном алгоритме прикладной задачи и о общении с БД на логическом уровне. Странно, что вы этого сразу вроде как не поняли. Все, что происходит на уровне физическом меня не интересует. Это дело СУБД и в ГТ.М оно реализовано в достаточной степени. И кстати, не знаете ли вы случайно как на физическом уровне хранятся данные в большинстве РБД. Не в виде ли блоков данных организованных в двоичные В деревья ? А если так, то не есть ли РБД иерархические ? Несмотря на наличие реляционного интерфейса. Как поживает ваш кадавр ? Мы его когда-нибудь увидим ?
8 янв 07, 01:43    [3612565]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
V52
Guest
vadiminfo
V52

По успешности чего ? Продаж и популярности ? Познер же объяснил нам, что популярной и успешной можно сделать лошадиную задницу если ее часто показывать людям. И она превзойдет по успешности кого-угодно. Все зависит от частоты показа. К сожалению, такая психология масс.

Успешности в технологиях БД. По числу успешных проектов, в том числе и достаточно крупных.
По числу инстоляций. Сегодня еще пока реляционная эпоха.


Я видел и вижу вокруг много "успешных" и крупных инсталяций. Успешные они на бумагах (актах сдачи в эксплуатацию) и крупные по сумме сделок. Провести успешную инсталяцию означает найти концы для выхода на руководство предприятия и предложить достаточно большой откат. В таких инсталяциях продавцы Р решений преуспели. Одни называют эту эпоху реляционной, но по моему больше подходит корупционная. Однако, я такие успешные инсталяции не засчитываю.
8 янв 07, 02:08    [3612579]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
c127
V52

Пример 2.
Если строка S1 состоит из элементов E1, E3, E9, E5
а строка S2 состоит из элементов E4, E9, E32, E1, E55, E71, E2
то из общих элементов E1, E9
должна быть построена новая строка S3 которая будет родителем для строк S1 и S2, а строки S1 и S2 будут соответственно потомками для строки S3.

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=71#3608936
Должен ли этот процесс продолжаться рекурсивно, т.е. должен ли он быть повторен для вновь образованных строк?


Поскольку ответ на этот вопрос вроде бы дан не был, в своем решении я не повторять процедцру рекурсивно, а построю только пересечение исходных множеств, как это и требуется по условию задачи. Если не ошибаюсь в приведенном решении на М так и делается. Хотя мне это представляется нелогичным.

Я также слегка изменню формат входного-выходного файла. Исходный входной файл преобразуется в требуемый для РСУБД решения с помощью утилиты на питоне, читает из "../i0.txt", пишет в stdout:
import sys, string

fl=open("i0.txt",'r')
f=fl.readlines()
fl.close()
for i in range(len(f)):
  if f[i].strip()=="": break
  s=f[i].split('*')
  for e in s:
    print 'S%i %s' % (i,e)
Для приведения выходного файла в требуемый формат нужно повозиться, но мне лень и я считаю, что для последующей машинной обработки мой формат удобнее, а если множеств много, то человеу его читать тоже легче.
Решение для сайбейз АСА 9.0.2, запускается в isql, читает из файла 'd:/tmp/i1.txt', пишет в файл 'd:/tmp/o0.txt':
//промежуточная таблица, нужна только если элементы в строке не уникальны
//если их уникальность гарантирована, то можно импортировать в таблицу s1
create table s0 (
  s varchar(16),
  e varchar(16)
  );

load into table s0
  from 'd:/tmp/i1.txt'
  delimited by ' ';

create table s1 (
  s varchar(16),
  e varchar(16),
  primary key(s,e)
  );

insert into s1 (s,e) (select distinct * from s0);
commit;

//пересечения
create view i as (
  select x.p p,x.q q,e
    from (select distinct p.s p,q.s q from s1 p, s1 q where p.s<q.s) x,
         lateral (  select e from s1 where s=x.p
                  intersect
                    select e from s1 where s=x.q) y
  );

//набор множеств, замкнутый относительно пересечений 
create view s as (
    select s,e from s1
  union all
    select p||q,e from i x
      where (select count(*) from s1 where s1.s=p)
           <>(select count(*) from i y where y.p=x.p and y.q=x.q) //не включать, если q есть подмножество p
  );

create view v as (
  select p,q,n np,k nq,n2 
    from (select count(*) n, s from s group by s) n,
         (select count(*) n2, p.s p, q.s q
            from s p join s q on (p.e=q.e)
            where p.s<>q.s
            group by p.s,q.s) m,
         (select count(*) k, s z from s group by s) k
  where s=p and q=z
  );

//промежуточный результат, если множества большие, то выводить их поэлементно в виде строк нет смысла.
//Лучше использовать это предствление
create view r as (
  select * from (
    select p,'=' r,q,np,nq,n2 from v where np=n2 and np=nq
  union all 
    select p,'<' r,q,np,nq,n2 from v where np=n2 and np<nq
  union all
    select p,'>' r,q,np,nq,n2 from v where nq=n2 and np>nq ) x
  );
//если после этого сказать 
//select * from r;
//output to 'd:/tmp/o0.txt';
//то вместо строк вида "E20*E33*E34" будут напечатаны имена множеств

//окончательный результат
select (select list(e,'*' order by e) from s where s=p),r,
       (select list(e,'*' order by e) from s where s=q)
  from r
  order by p,r,q;
  output to 'd:/tmp/o0.txt';

Пример.
i0.txt:
E1*E3*E15*E4*E8*E22*E3
E1*E3*E92*E15*E4*E45*E8*E22*E33
E1*E3*E9*E5
E4*E9*E32*E1*E55*E71*E2
E1*E3*E15*E4*E8*E22*E3
i1.txt:
S0 E1
S0 E3
S0 E15
S0 E4
S0 E8
S0 E22
S0 E3

S1 E1
S1 E3
S1 E92
S1 E15
S1 E4
S1 E45
S1 E8
S1 E22
S1 E33

S2 E1
S2 E3
S2 E9
S2 E5

S3 E4
S3 E9
S3 E32
S3 E1
S3 E55
S3 E71
S3 E2

S4 E1
S4 E3
S4 E15
S4 E4
S4 E8
S4 E22
S4 E3

o0.txt (приведен частично):
'E1*E3*E15*E4*E8*E22','<','E1*E3*E92*E15*E4*E45*E8*E22*E33'
'E1*E3*E15*E4*E8*E22','=','E1*E15*E22*E3*E4*E8'
'E1*E3*E15*E4*E8*E22','=','E1*E15*E22*E3*E4*E8'
'E1*E3*E15*E4*E8*E22','=','E1*E15*E22*E3*E4*E8'
'E1*E3*E15*E4*E8*E22','=','E1*E3*E15*E4*E8*E22'
'E1*E3*E15*E4*E8*E22','>','E1*E3'
'E1*E3*E15*E4*E8*E22','>','E1*E4'
'E1*E3*E15*E4*E8*E22','>','E1*E3'
'E1*E3*E15*E4*E8*E22','>','E1*E4'
'E1*E3*E15*E4*E8*E22','>','E1*E3'
'E1*E3*E15*E4*E8*E22','>','E1*E4'
'E1*E15*E22*E3*E4*E8','<','E1*E3*E92*E15*E4*E45*E8*E22*E33'
'E1*E15*E22*E3*E4*E8','=','E1*E3*E15*E4*E8*E22'
'E1*E15*E22*E3*E4*E8','=','E1*E15*E22*E3*E4*E8'
'E1*E15*E22*E3*E4*E8','=','E1*E15*E22*E3*E4*E8'
'E1*E15*E22*E3*E4*E8','=','E1*E3*E15*E4*E8*E22'
'E1*E15*E22*E3*E4*E8','>','E1*E3'
'E1*E15*E22*E3*E4*E8','>','E1*E4'
'E1*E15*E22*E3*E4*E8','>','E1*E3'
............
............
............
'E1*E4','<','E4*E9*E32*E1*E55*E71*E2'
'E1*E4','<','E1*E3*E15*E4*E8*E22'
'E1*E4','=','E1*E4'
'E1*E4','=','E1*E4'
'E1*E3*E15*E4*E8*E22','<','E1*E3*E92*E15*E4*E45*E8*E22*E33'
'E1*E3*E15*E4*E8*E22','=','E1*E3*E15*E4*E8*E22'
'E1*E3*E15*E4*E8*E22','=','E1*E15*E22*E3*E4*E8'
'E1*E3*E15*E4*E8*E22','=','E1*E15*E22*E3*E4*E8'
'E1*E3*E15*E4*E8*E22','=','E1*E15*E22*E3*E4*E8'
'E1*E3*E15*E4*E8*E22','>','E1*E3'
'E1*E3*E15*E4*E8*E22','>','E1*E4'
'E1*E3*E15*E4*E8*E22','>','E1*E3'
'E1*E3*E15*E4*E8*E22','>','E1*E4'
'E1*E3*E15*E4*E8*E22','>','E1*E3'
'E1*E3*E15*E4*E8*E22','>','E1*E4'
"Parents","Children","Brothers" заменены на "<",">","=" соответственно. По-моему так удобнее.
8 янв 07, 02:23    [3612585]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
frutalino
> Дело в том, что в M&Cache база умеет «заползать» с сервера в озу М-клиентов и там обрабатываться локально, вообще не паря сервер.

Как «распараллелить» базу РСУБД для меня загадка.
Сейчас конечно кто-то скажет про «кластер», но кто его видел это кластер?

Ну и каков коэффицент «распараллеливания» достигнут?
И что там с дисковой системой этого кластера?

Все это весьма туманно и нетривиально с технической точки зрения.

Мораль такая (меня в любых спорах привлекают именно моральные аспекты) – если вам не нужна мощность – вам М программы не нужны.

Если у вас – полтора юзера – вам М программы не нужны.

М программа – это 1000 запросов юзеров в секунду – поймите это один раз и навсегда.
Там некогда «парсить» SQL.


Фруталино, "заползать с сервера в озу клиента" умеет любая программа, использующая ODBC курсоры на клиенте. А если для вас загадка, как распараллелить РСУБД, и вы кластеров в глаза не видели - то вам, мне кажется, лучше не с заявлениями выступать, а немного подучиться.
Я рад, что вы понимаете, что "все это весьма туманно и нетривиально". Об этом и речь - то, над чем в РСУБД годами работали очень незаурядные умы, в М-системах предлагается склепать на коленке.
8 янв 07, 02:51    [3612601]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
V52

Я видел и вижу вокруг много "успешных" и крупных инсталяций. Успешные они на бумагах (актах сдачи в эксплуатацию) и крупные по сумме сделок. Провести успешную инсталяцию означает найти концы для выхода на руководство предприятия и предложить достаточно большой откат. В таких инсталяциях продавцы Р решений преуспели. Одни называют эту эпоху реляционной, но по моему больше подходит корупционная. Однако, я такие успешные инсталяции не засчитываю.

Этих инстоляций более 90% от всех приложений БД. Вы все эти проекты по всему миру исследовали на успешность? В самых богатых организациях? Они все не удачные?
Проекты с Мумпсом везде без достаточно больших откатов? Чисто на пропаганду клюнуло руководсто предприятия?
Эпоху называют реляционной не только они. Откуда по Вашему термин Постреляционная СУБД Каша? Книга с таким названием стоит счас в во многих книжных магазинах. Разве это не означает, что представители Каши признают реляционную эпоху? Могли бы назвать посткоррупционная СУБД Каша.
Я уже не говорю про высшее образование по ИС. Преподы по БД вроде про это читают. Им тоже откатили или массы одураченные по Позднеру?
Вы, конечно, кроме М не склонны ничего засчитывать. Но мы с Вами не объективны - потому кого заинтересует что мы там засчитываем, а что нет?
Засчитали другие. Думаю пограмотнее нас с ВАми там найдутся.
8 янв 07, 03:03    [3612604]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
V52
Выбегалло
V52

Отсюда вытекает эффективность использования М. Кто бы что ни говорил, но программу написать – раз плюнуть, если известно, что и как надо писать. Т.е. основная трудоемкость программирования – разработка ОПТИМАЛЬНОГО алгоритма. Абсолютное отсутствие в М ограничений на структуры данных позволяет разрабатывать наиболее оптимальные алгоритмы за наименьшее время. Именно поэтому я являюсь его сторонником.

Да, в исходном М нет SQL и его центральной части – оператора SELECT. Потому что он НЕ НУЖЕН так как М позволяет строить алгоритмы с превалирующим ПРЯМЫМ обращением к данным, а не через механизм последовательной выборки. А для организации последовательной выборки можно организовать один-два цикла с условиями отбора, что по трудоемкости написания не превышает изображение SELECTa.


Кто вам сказал, что для сложных выборок прямой перебор с внутренними циклами - "наиболее оптимальный алгоритм" ? Умеете ли вы "за наименьшее время" написать алгоритм выборки с использованием хэш-таблиц ? А с индексами ? А с read-ahead ? А с фрагментированием по разным дискам для распараллеливания IO? А fragment elimination сделаете ? А сумеете самостоятельно написать оптимизатор, который будет анализировать предполагаемую стоимость выборки и принимать решение, каким из вариантов пользоваться ? А как у вас с написанием, за наименьшее время, поддержки транзакций ? Блокировки, откаты, разные степени изоляции - легко и просто ? за три дня управитесь ? А как насчет кеширования - имеете доступ под капот M, сможете его заставить часто используемые данные хранить в памяти ? Какой процент ваших read-ов лезет на диск за данными, а какой - использует уже имеющиеся в буферах ?

MUMPS - это не СУБД. Это набор "сделай сам".


Уважаемый професор! Практически ничего из перечисленного вами мне делать не приходится. Я говорил об оптимальном алгоритме прикладной задачи и о общении с БД на логическом уровне. Странно, что вы этого сразу вроде как не поняли.


То есть у вас пока такого класса задачи, что вам ни индексы не нужны, ни оптимальные планы запросов, ни транзакции ? Ну вы бы сразу и сказали, мол, М хорош как заменитель Фокса, а на звание enterprise СУБД он не претендует.


V52
Все, что происходит на уровне физическом меня не интересует. Это дело СУБД и в ГТ.М оно реализовано в достаточной степени. И кстати, не знаете ли вы случайно как на физическом уровне хранятся данные в большинстве РБД. Не в виде ли блоков данных организованных в двоичные В деревья ? А если так, то не есть ли РБД иерархические ? Несмотря на наличие реляционного интерфейса. Как поживает ваш кадавр ? Мы его когда-нибудь увидим ?


Сначала вы рассказываете, как хорош М тем, что позволяет писать оптимальные алгоритмы доступа. Теперь оказывается, что все, что вы делаете - это перебор в цикле. И вас при этом не интересует, что у него происходит под капотом. Ну бывает. Задача вам попалась такая... нетребовательная. Хотел бы я посмотреть, как будет выглядеть (а главное - сколько будет выполняться) какой-нибудь звездообразный запрос на таблице в пару терабайт.

А как на физическом уровне организованы данные в СУБД, я, как бывший инженер саппорта Informix, случайно знаю. Постранично они организованы в большинстве случаев. И нет, страничная организация и наличие B-trees не делает эти РБД иерархическими.

А насчет кадавра - будет вам кадавр. Вот выйду в понедельник на работу и изображу, не в воскресный вечер же работать, тем более Рождественский :-)
8 янв 07, 03:16    [3612609]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
V52
vadiminfo
V52

По успешности чего ? Продаж и популярности ? Познер же объяснил нам, что популярной и успешной можно сделать лошадиную задницу если ее часто показывать людям. И она превзойдет по успешности кого-угодно. Все зависит от частоты показа. К сожалению, такая психология масс.

Успешности в технологиях БД. По числу успешных проектов, в том числе и достаточно крупных.
По числу инстоляций. Сегодня еще пока реляционная эпоха.


Я видел и вижу вокруг много "успешных" и крупных инсталяций. Успешные они на бумагах (актах сдачи в эксплуатацию) и крупные по сумме сделок. Провести успешную инсталяцию означает найти концы для выхода на руководство предприятия и предложить достаточно большой откат. В таких инсталяциях продавцы Р решений преуспели. Одни называют эту эпоху реляционной, но по моему больше подходит корупционная. Однако, я такие успешные инсталяции не засчитываю.


Лично я видел вполне успешные терабайтные базы на Informix, DB2, Sybase IQ, Teradata. Не сомневаюсь, что сушествуют такие на Oracle и MSSQL. А вот насчет MUMPS - меня терзают смутные сомнения...
Кстати, про откаты и успешные внедрения - сурпрайз, сурпрайз, не одни продавцы реляционных баз этим грешат. Читайте
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=363319&pg=1
и в топике
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=363319&pg=4#3433137
8 янв 07, 03:27    [3612616]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
V52
Позвольте мне сказать, что я считаю в М главным и в чем я вижу его преимущество перед Р системами.

Если вы обратили внимание на работу с базой данных в моем примере, то вы увидели, что работа программы со структурами данных, расположенными в БД, ничем не отличается от работы с локальными переменными или массивами, находящимися в оперативной памяти. Вся разница – в наличии символа “^” (caret или циркумфлекс) перед именем переменной. Нет символа – переменная в ОП, есть – переменная да диске в БД. Таким образом, база данных М системы является неограниченным расширением оперативной памяти и в ней могут быть сохранены любые структуры данных простым добавлением символа “^” перед именем переменной. Из этого вытекает также, что все команды и функции языка, работающие с какими-либо переменными, массивами или строками или с какими угодно структурами данных пригодны также для непосредственной работы с БД.


Я Вас разочарую, если Вы действительно считаете это преимуществом. В СКЛ серверах вообще не требуется ничего подобного символу '^' перед именами, разницы в том, где находятся данные нет никакой. С точки зрения программиста работа с ними одинаковая, независимо лежат ли они на диске или прокешироаны и лежат в памяти, сервер сам решает куда положить данные.

V52

Теперь о модели данных. Кто-то когда-то где-то по своей неполноте знаний сказал, что М это иерархическая БД. Это подхватили сторонники Р концепции для того, чтобы можно было называть М СУБД иерархической и устаревшей, а мы, мол, работаем с Р, а это «суперсовременно». Модель данных М СУБД НЕ ИЕРАРХИЧЕСКАЯ. М СУБД МОЖЕТ хранить иерархические структуры, также как и реляционные таблицы, также как и сетевые и любые другие структуры. Изобразите нужную структуру данных в ОЗУ, добавьте спереди “^” и вы получите структуру БД. Т.е. М не зажата в рамках никакой парадигмы и Р это частный случай М.

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

V52

Отсюда вытекает эффективность использования М. Кто бы что ни говорил, но программу написать – раз плюнуть, если известно, что и как надо писать. Т.е. основная трудоемкость программирования – разработка ОПТИМАЛЬНОГО алгоритма. Абсолютное отсутствие в М ограничений на структуры данных позволяет разрабатывать наиболее оптимальные алгоритмы за наименьшее время. Именно поэтому я являюсь его сторонником.

Ничего отсюда не вытекает кроме дополнительной головной боли от борьбы с излишней гибкостью в конкретной задаче. Когда задача конкретизирована, то излишняя гибкость всегда недостаток. Вам же нужно все средства, кроме базовых (а их с необходимостью мало, ибо в М "Абсолютное отсутствие ... ограничений на структуры данных"), создавать руками.

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

V52

Да, в исходном М нет SQL и его центральной части – оператора SELECT. Потому что он НЕ НУЖЕН так как М позволяет строить алгоритмы с превалирующим ПРЯМЫМ обращением к данным, а не через механизм последовательной выборки. А для организации последовательной выборки можно организовать один-два цикла с условиями отбора, что по трудоемкости написания не превышает изображение SELECTa.

Вы вообще хоть имеете представление об РСУБД и СКЛ-е? По-моему нет, ибо не путали бы язык со способом доступа к данным. РСУБД были созданы, чтобы этот дотуп от программиста скрыть. Читайте классиков.

Если не нравится последовательная выборка - организуйте индекс. Это обсуждалось тут раз 20, но каждый новый адепт считает своим долгом блеснуть эрудицией.

V52

В итоге можно сказать, что М – это универсальная глобальная концепция, а Р – ее частный случай который сектанты возвели в ранг самостоятельной религии, воздвигли себе идола в виде оператора SELECT и пляшут вокруг него с бубнаим цепляя бусы и цветные лоскутки в виде всяких WHERE и FROM.

В итоге можно сказать, что Вы так ничего и не поняли в РСУБД, даже если и пытались когда-то разобраться, в чем я сомневаюсь. Читайте мой ответ на предыдущее Ваше утверждение, но все-таки лучше почитайте классиков.



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

Поэтому ждать какого-либо выигрыша по сравнению с другими процедурными языками не имеет смысла, они все по определению отличаются только в мелочах. С другой стороны СКЛ язык декларативный, это другой класс языков. У него куча своих недостатков, например значительно тяжелее построить хороший оптимизатор. Но если это сделано, то СКЛ на определенных задачах (не всех конечно) позволяет существенно экономить труд разарботчика.

Несущественным в принципе отличием М от С и паскаля есть отсутствие типов, все хранится в строках, если я правильно понял. Некоторыми это почему-то считается большим достоинством, но на самом деле это большой недостаток, ибо поиск ошибок в бестиповых языках сильно затруднен. А программ без ошибок не бывает, даже если писать их "раз плюнуть". Плюнуть легко, а вот ошибки найти трудно. Разумеется еще страдает быстродействие такой программы, но это уже мелочи. Этот недостаток бестиповых языков был многократно проверен на практике и серьезные люди, например Вирт, уделяли типизации основное место в своих работах. Почему это так трудно доходит до некоторых, я не понимаю. Маленькие программы на бестиповом языке пишутся легче, но очень быстро с ростом длинны программы бестиповость превращается в недостаток и начинает сильно мешать. Я понимаю, что типы в М на раз плюнуть можно построить руками, поэтому экономьте время, не приводите этот аргумент в очередной раз.

Это все ИМХО разумеется.
8 янв 07, 03:43    [3612620]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
frutalino

Итак дискуссия постепенно подошла к преимуществам М&Cache.

Т.е. до этого дисскуссия показывала недостаки М&Cache?

frutalino


- Сколько СУБД в РСУБД?
Одна. Она крутится на сервере.

СУБД то одна, а экземпяров крутиться на сервере может не один. На каждом кластере по одному, например.

frutalino

- Сколько процессоров крутит РСУБД?
Столько, сколько есть на сервере.


- А сколько на сервере процессоров?
2? 4?
И сколько озу на сервере?
10Г? А может 80Г? О! Это ларджест сервер c 4-мя процессорами! За $40 тыс.

Посмротрите на тестах ТРС. Там по 32 есть. В кластер можно объеденить - будет 64.

frutalino


В Cache уже сегодня де-факто 1 базу может именно ПАРАЛЛЕЛЬНО крутить 256 процессоров Sempron на 256 PC с общим озу равным озу на одном PC* количество PC, т.е. если в каждом PC 8Г озу мы получаем фантазийную цифру – 2048Г озу – и это еще не учтен сам сервер.

Это по типу файл сервера что-ли? Или СУБД Каша тепрь ин мемори с такой то памятью?

frutalino


(отбросим деньги – но какая система будет мощнее?)

Тесты нужно типа TPC смотреть. Иначе как?

frutalino


Дело в том, что в M&Cache база умеет «заползать» с сервера в озу М-клиентов и там обрабатываться локально, вообще не паря сервер.



Опять спрашую: часом не по типу файл серверных СУБД? Как Аксцесс например?
Кстати, Оракл 10 версии называет себя Грид Oracle10g. Я, правда, не вникал, но типа паралельные решения. Значит скоро все будут гридами, скорее всего. Думаю, вопрос не в СУБД, а достижений в паралельных вычислениях вообще.

frutalino

Как «распараллелить» базу РСУБД для меня загадка.

Ну, сложная задача. Но врядли Каши в паралельных вычислениях сделала открытия никому до селе не известные. Фирма, скорее всего, забила бы на Кашу, и занялась созданием систем с параллельными вычислениями. Потому что судьба Каши еще не известна, а лидерство в ПВ дало бы большущие прибыли.

frutalino

Мораль такая (меня в любых спорах привлекают именно моральные аспекты) – если вам не нужна мощность – вам М программы не нужны.

Пока М не нужна не зависимо от нужности мощности. У ней с МД заморочки.

frutalino

М программа – это 1000 запросов юзеров в секунду – поймите это один раз и навсегда.
Там некогда «парсить» SQL.

Парсить SQL? Да полный парсинг у частых запросов выполняется достаточно редко.
А вот к примеру прочитать данные с диска куда больше времени.
Например, - с 800 приборов снимается 16 млн показаний в месяц - 142 млн в год.
Запрос показать среднюю за неделю средние данные по выбранному прибору.
Вы таких выполните 1000 в секунду? Одновремнно для разных приборов за разное время? На раз? Восхищаюсь. Оракл выполнял за несколько сек в одном проекте. Этого было достаточно. Потому все равно выберу пока его. Он в остальном хорош.

frutalino


Все это придумано не мной, а просто были люди которые выжимали из селекта, выжимали – плюнули на него и перешли на М.

Жаль что не Вами - счас бы большие бабки срубили и с нами поделились.
Да были люди и, к счастью, придумали селекты (РБД). А придумай это мы с Вами, счас бы много больше бабок срубили, чем те первые люди, что с селектом не справились и на М перешли.
8 янв 07, 03:47    [3612621]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
Ptn
Lepsik]>>хотите тягаться с С++ - смешно

То что вы читаете по диоганали ? ну наверное действиетельно смешно - сравнивают не языки.

Поступило предложение сравнивать кол-во строк и скорость.



кол-во строк сравнивать смешно - я читаемость считаю немаловажной.
сравнивать надо исполнимый код.

int rem(std::string const &number)
{
    int result = 0;
    for (unsigned i = 0; i < number.size(); ++i)
    {
        result = 10*result + number[i] - '0';
        result %= 11;
    }
    
    return result;
}

ну а сравнивать интерприруемые языки с компилируемым - это даже не смешно. С MSSQL2005 C++ идет в составе студи, так что можно его считать родным. Тем более что в DB2 он по жизни был чуть ли единственным средством программирования
8 янв 07, 05:56    [3612647]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
ну а если размер так важен то :

int r=0;for(int i=0;i<n.size();++i){r=10*r+n[i]-'0';r%=11;}cout<<r;
8 янв 07, 06:01    [3612650]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
vadiminfo >>Но главное в Джаве язык, а в СУБД МД, которую(ые) она поддерживает.

Не знаю не знаю - для меня вот - фреймворк важнее.

>>Это означает обоснование сомнений в том, М - СУБД.
"Java это язык". так кажется. Ну прежположим что я с вами тут соглашусь - с наличием соменений. Дальше то что ? ;)

Ptn

Есть SQL - БД называется SQL-сервер. Это общеупотребимое но некорректное название. И что дальше ?

>>Не понял к чему это.

Это было к вопросу что первое приходить в голову при слове Java. И почему понятия М-язык и М-система обычно не разделяются.

>>Если для поодержания БД понадобится ЕЩЕ один язык входящий в лидеры языков (а не какой попало)
Нет как раз не так - не нужен никакой лидирующий язык - но я могу сделать простой скриптовый язык - что бы юзеры могли писать отчеты прямо в интерфейсе приложения.


>>Подобные сомнения высказывались и другими.
Я верю - и опять таки - и что ?
Вот есть у меня ООП в проекте хоть ты тресни и работаю я на Каше.
Переубеждать пол форума ? нет - такой задачи нет.

>>Мне достаточно, что Вы признали вопрос открытым.
Хорошо

>>Однако, до сих пор их мнение, особенно в обласи науки и техники, имеет значение.
>>Ничего не попишешь.

Если не ошибаюсь это называется научная парадигма.

>>В таком случае, М не просто СУБД, но и в частности РСУБД, т.е. на "общеупторебимом" - SQL - сервер. Или там другой реляционный язык (не SQL)?

Со стороны ODBC это обыкновеннейший SQL-сервер.

>>Он в Вашем лагере - ярый мумпсист.
Ну значить тогда Я сам по себе.

Ptn

Хм - это надо обсуждать в ветке по Каше. К сути здешней дисскуии это не имеет ровно никакого отношения.

>>Здесь ветка про сравнении Каши со Скулем (MSSQL).
И если её внимательно прочитать то можно увидеть что сравнение как таковое отсутствует.

>>Если к ней негативно относятся мумпсисты, в то время как она "М-система", это, скорей всего, не такой уж и большой плюс в этом сравнении.
Насколько я знаю негатив связан с тем что ISC выкупила фирмы и патенты связанные с М - и сейчас волевым решением выдвигает на передний план Cache, задвигая на задний ДТМ и МСМ.

Маркетинг дело грязное - но к М он не имеет никакого отношения.

>>Но для этого нужна заинтересованность.
Ну спрашивайте :) - пока же только обсуждаем толкование слова М.

>>Это ставит под сомнение ООМД в М.
Нет - его там и не было. Я уже говорил ООП появляется на уровень выше.

>>А вы говорили любая МД в М.
Такое мое мнение (с)

>>Т.е. с любыми МД в М не все так очевидно.
Возможно

О "тройствености" МД. И если эти МД там сильно представлены, то это не просто в ряде случаев привлекло бы внимание, а просто поставило бы ее над всеми другими СУБД. И она бы реально претендовала быть постреляционной СУБД.
Простите ... а разве это не так ?

>>Т.е. Вы сравниваете только в плане кол-ва инструментов в линейке разработке?
Этот критерий нельзя сбрасывать со счетов - но конечно же он не единственный

>>Может лучше разные специализированные на своих подзадачах, чем одно универсальное (интегрированное).
Лучше конечно (знали бы вы как я матерился, когда делали пункт приема платежей на WEB).
Но не всегда "выгоднее" "оправданнее" и "быстрее"

>>Например, для клиентов лучше Джава или Дельфи или Басик, чем М.
Нет никаких ограничений. Но TCP-сервер, когда клиенту потребовалось общаться по хитрому протоколу, я написал на М. Страницу занял.

>>Да и насчет разницы - могие файлсерверные СУБД тоже ни в чем не нуждаются.Акцесс, Фокспро.

И были жутко популярны - увы - сеть сделала свое дело.

>>Я так понял может выступать как РСУБД.
Может - но не только - поэтому ISC настаивает на другом термине.
Куб со стороны тоже квадрат - но всё таки он не квадрат.

>>Не понял почему это может привлечь при выборе Каши против MSSQL.
Быстрая разработка WEB приложений

С другой стороны, СУБД, как правило стремится обеспечить работу с данными БД разных прог, в силу того, что БД в силу основной своей идеи в ИТ предназначена для разных прог, в общем случае на разных языках.
У меня подозрение что вы говорите про клиентскую часть - с этим Каша ничем не отличается от остальных СУБД - да и серверную часть никто не мешает делать через call-in.

>>А там еще есть Джава. Однако, важнейшим в успехе РСУБД является именно SQL.
Да пусть и джава будет. - Но не PHP

>>Это позволяет легко извлекать достаточно сложную информацию во многих случаях.
Именно поэтому мы в отчетам его и используем ... с редкими оптимизациями на М.

>>Потому сравнеие только с PL/SQL не поможет даже если М превзойдет его.
Ну и о чём тогда спор ;)))

>>А в развитии языков с тех произошли кое-какие изменения.
Спасибо - напомнили В COS появилось управление областью видимости.

>>Т.е. это не плюс для М без дополнительных уточнений.
Стандарт Языка на то и Стандарт что бы не приписывать ничего более. В реализациях стандарта можно найти кое-какие изменения.

Язык SQL - именно специализированный язык БД. Поэтому не понял про какую проблему Вы говорите.

Это проблема понимания что такое язык БД и какав он может быть. (Как и в случае с джавой)

Как вы и указали SQL это специализированный язык. А вот М -неспециализированный.

Но в сравнениях это постоянно забывают.
Порой указывая на более широкий профиль М как на недостаток - что совершенно неясно.
8 янв 07, 09:06    [3612746]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
DocAl>>Аббревиатура UDF вызывает у вас какие-либо ассоциации? Это о том, откуда берутся C(++) и Java.

Вообще то про них и речь.

>>Пример на PHP был приведён просто потому, что а) показывает, что задача не имеет ни малейшего отношения к СУБД и б) потому что у PHP достаточно понятный C-подобный синтаксис, который, IMHO, конечно, будет более понятен для большинства читателей, чем конструкции типа "^ s f a" M-решения.

а) задача полностью укладывается в фукнцианал UDF
б) еще раз - у нас М-система - примеры будут на М. Что без этого сравнивать то ?

Ну давайте вы приведе пример UDF на С и мы сделаем абсолютно то же самое - что сравнивать изволите ???

Или диалекты SQL начнем сравнивать что ли ?

А вот когда UDF (на JAVA ли на C ли на PL/SQL ли) в полной обвязке будет готова тогда и можно оценить сколько времени и усилий затрачено на её создание, отладку и регистрацию в БД и сколько на М программу реализующую абсолютно тоже самое.
8 янв 07, 09:14    [3612752]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
c127
Я Вас разочарую, если Вы действительно считаете это преимуществом. В СКЛ серверах вообще не требуется ничего подобного символу '^' перед именами, разницы в том, где находятся данные нет никакой. С точки зрения программиста работа с ними одинаковая, независимо лежат ли они на диске или прокешироаны и лежат в памяти, сервер сам решает куда положить данные.

и меня тоже...
я не знал об этом, когда делал declare @a для объявления переменных в памяти, и зачем то insert into ... или update для записи.
8 янв 07, 09:28    [3612766]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло>>ну показывайте.
Ну читайте - тут вам и про Хеш и про многое другое

>>ECP ? Short for Extended Capabilities Port,
И еще много умных слов.

>>В том то и дело, что "в упрощенном виде". Ну очень упрощенном.

Уважаемый - а мне и нужно в упрощенном.
В неупрощенном использую SQL + модификатор %FULL и не парю себе голову - пусть оптимизатор БД планы перебирает.
С той лишь разницей что я всегда могу посмотреть чего он там сделал и сделать компиляцию из нескольких ЕГО вариантов.

>>Название доки, номер страницы ?
Вы не поверите - дока на сайте ISC

>>насчет ms sql не знаю, а в информиксе onstat -p все прекрасно показывает :

У нас тоже есть утилиты мониторинга в том числе и для оценки эффективности настроек кэша.
и что ?

>>И самый цимес в том, что ну абсолютно ничего делать не надо - все уже сделано до вас.
Да наздоровье.
8 янв 07, 09:35    [3612777]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
c127 Будьте любезны, изобразите таблицу из трех полей типа целое, с ключом по одному из них и индексом по двум другим. Разумеется индекс должени автоматически поддерживаться при изменеии данных.

Class T.T Extends %Persistent 
{

Property a1 As %Integer [ Required ];

Property a2 As %Integer [ Required ];

Property a3 As %Integer [ Required ];

Index a1Index On a1 [ IdKey, Unique ];

Index a2Index On (a2, a3);

}
8 янв 07, 09:43    [3612789]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Скриншот с созданной таблицей

К сообщению приложен файл. Размер - 0Kb
8 янв 07, 09:49    [3612800]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Lepsik>>кол-во строк сравнивать смешно - я читаемость считаю немаловажной.

Про что и речь. Но ведь нам предлагают именно это .

>>сравнивать надо исполнимый код.

Вот вот - где в вашем коде доступ к данным ?

>>ну а сравнивать интерприруемые языки с компилируемым - это даже не смешно.

Осталось найти этих юмористов. ;)

>>Тем более что в DB2 он по жизни был чуть ли единственным средством программирования

А в Cach'e он один из многих и что ?
8 янв 07, 09:55    [3612805]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Прошу прощения за болд - я не могу исправлять сообщения
Модератор: ну неужели так трудно выделить нужный кусок текста мышом
и мачкнуть пимпочку QUOTE, или B, раз уж вам она так нравится...
нужно обязательно тыркать коды форматирования руками и при этом непременно промахиваться...
кстати, тут ещё и "Предварительный просмотр" есть.
вы не в курсе?


Сообщение было отредактировано: 11 янв 07, 11:46
8 янв 07, 09:58    [3612811]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
))
iscrafm
Дорогой инопланетный друг... было сказано и написано без всяких физиономий, т.е. на земном языке это означает - серьезно.

кто бы усомнился. как вы сказали?... чем больше - тем лучше? записал на жесткий диск

в мире еще много чего необычного и интересного. поэтому пока молодой нужно учиться.
8 янв 07, 10:11    [3612825]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 70 71 72 73 74 [75] 76 77 78 79 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить