Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 15 [16] 17 18 19   вперед  Ctrl
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
mir
Маленький комментарий. Реляционная модель чисто логическая и не имеет отношения к физическим структурам и принципам хранения. Хорошо бы вам сразу на берегу это признать.

запросто. ну вот, признал. что изменилось? вот я смотрю, что в MySQL, в
MS SQL и в Clarion размер БД почти одинаков. желающие могут полезть
в Oracle, SyBase и иже с ними, и получить примерно такую же картину.
выводы?

mir

И конкретные структуры хранения являются особенностями реализации конкретной РСУБД. И таковых множество. Хранение по строкам, да еще и с фиксированном их размером есть только один из подходов. Есть хранение по столбцам (см. Sybase IQ), есть IOT (Oracle), есть модель TransRelational. Да и "по строкам" хранять можно по разному.
Не ясно, почему вы с таким упорством говорите о "реляционных структурах" физического хранения, ведь такого понятия просто не существует.

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

С уважением. Сергей
10 май 06, 16:35    [2648748]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
ну я
Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал.
Создаётся впечатление, как будто только Каше так поступает :-)))

например? я с удовольствием послушаю

С уважением. Сергей
10 май 06, 16:39    [2648787]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
pavelvp
Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал.
Создаётся впечатление, как будто только Каше так поступает :-)))

Жаль, что так получилось. Разговор же шел про каше, я про эту СУБД и писал.
10 май 06, 16:59    [2648936]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
запускаешь терминал, d ^tmp
Легко сказать :-) Как его запустить то. У меня создана база MMM. Как мне к этой базе прицепится?
Что и где нужно сконфигурить, чтобы вместо
USER>
я бы увидел
TRD>
10 май 06, 17:24    [2649139]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
pavelvp

Что и где нужно сконфигурить, чтобы вместо
USER>
я бы увидел
TRD>

Да можно и на ходу пеерскочить
USER>zn "TRD"
TRD>
10 май 06, 17:28    [2649155]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
pavelvp
Sergei Obrastsov
запускаешь терминал, d ^tmp
Легко сказать :-) Как его запустить то. У меня создана база MMM. Как мне к этой базе прицепится?
Что и где нужно сконфигурить, чтобы вместо
USER>
я бы увидел
TRD>

В трее иконка, из нее - панель управления. Там слева безопасность, в ней бюджеты пользователей, В редактировании пользователя комбобокс с областью куда его пускать по умолчанию. Локальный терминал заходит как пользователь TRM.
10 май 06, 17:38    [2649218]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
комментатор
Guest
Еще проще
USER>zn "trd"
чем
USER>zn "TRD"
10 май 06, 17:41    [2649236]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
pavelvp
Member

Откуда:
Сообщений: 673
LittleCat
Да можно и на ходу пеерскочить
USER>zn "TRD"
О! Спасибо! А то у меня в кешовой панели никакой безопасности и никаких бюджетов пользователей нет.
Итак, господа. По пунктам.

Sergei Obrastsov
"эмулированную подсистему хранения данных для эмулированного SQL" и хочешь назвать это оптимальной системой.
Система хранения данных одна. Нечего там эмулировать.

а у тебя в РСУБД не так? или ты полагаешь, что VARCHAR(x) не есть указание
на предельный размер поля? не надо быть наивным
Не так. Х - это максимальный размер, а не фиксированный. Чего там для его эмуляции нужно - я не понимаю. А про какие ты описания полей твердишь, так совсем не ясно... И что это за реляционные структуры - тоже непонятно. Ты же не знаешь как в конкретных СУБД данные хранятся - о чём тогда ты говоришь?

Создаётся впечатление, как будто только Каше так поступает :-)))
например? я с удовольствием послушаю
Префиксное сжатие индексов у всех нормальных СУБД. У нас есть. И никакой дурак не будт хранить повторяющиеся ключи.

А теперь результаты, которые я получил загружая не тупо, по-настоящему.
Т.е. результаты честного теста (не совсем честно, т.к. структура данных была потеряна):
- Загрузка шла весьма шустренько - ничего удивительного, т.к. фактически шло "тупое" построение деревяхи с одним ключом.
- "оптимальный" размер файла cache.dat получился 208 мегов :-)))
Разница в 26 метров, от тех "неоптимальных" 234-х, получилась видимо за счёт отсутсвия 59 полей :-)

Что же я получил. Полное отсутствие структуры данных со всеми вытекающими и почти в 2 раза больший объём БД. Выигрышь только в скорости загрузки. И тот сомнительный... Нужно попробовать грузить в ЛИНТЕР тоже одной такой строкой.

Что опять я делал не так?
10 май 06, 18:36    [2649488]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
pavelvp
[quot Sergei Obrastsov]Зачем??? И какой идеологии? Пока мы выяснили, что фиксированные размеры полей у DBF (причём здесь РСУБД?) и у одной из версий DB2.

Ой. А когда мы это выяснили? Может, мы не сходили по ссылке, приведённой ggv, а просто решили, что она подтверждает слова Демидова? Или Демидов объяснил нам внятно, что он имеет в виду?
10 май 06, 20:28    [2649775]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Я немного выпал из обсуждения, за что прошу прощения.
Следуя ссылке ggv мы попадаем на доку по совсем свеженькой V5R4 (не знаю никого, у кого бы она уже стояла).
Впрочем, не важно.
Итак, номер один - лёгкость использования - читаем :
V5R4
In COBOL and C, varying-length character strings are represented as structures.
In C, varying-length character-string variables can also be represented by NUL-terminated strings. - везде бы так просто реализовали
...
CLOB varying-length character-string variables can be defined in all host languages except REXX, RPG/400, and COBOL/400.

Надеюсь, перевод не нужен? Или пространные объяснения о "простоте" сравнения двух строк VARCHAR на Коболе, которые на самом деле структуры?

Номер два: качество имплементации в БД (ладно, ладно, ожидая шквал возмущений от ggv и ко. перефразирую это в "особенности реализации")
Tips for using VARCHAR and VARGRAPHIC data types in databases
Там говорится о том, что VARCHAR это всё равно фиксированный CHAR плюс опциональный сегмент, за который вы заплатите дополнительным i/o


--
Антон
Per rectum ad astrum
10 май 06, 21:10    [2649860]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Sergei Obrastsov
"эмулированную подсистему хранения данных для эмулированного SQL" и хочешь назвать это оптимальной системой.
Система хранения данных одна. Нечего там эмулировать.

ай, неправ, дарагой... есть там чего эмулировать и есть там чего скривлять
и выпрямлять. :) (сейчас меня опять обвинят в голословности). ну ладно:
таблицу вида поле1_поле2_поле3_...полеN в строке, № строки в столбце,
можно записать так

^table(n_строки)=поле1*поле2*поле3...*полеN

а можно так:

^table(n_строки,1)=поле1
^table(n_строки,2)=поле2
...
^table(n_строки,N)=полеN

вторая структура, как видишь, неоптимальна. и это только данные.
об индексации стоит говорить или экстраполируешь сам? :)

pavelvp

а у тебя в РСУБД не так? или ты полагаешь, что VARCHAR(x) не есть указание
на предельный размер поля? не надо быть наивным
Не так. Х - это максимальный размер, а не фиксированный. Чего там для его эмуляции нужно - я не понимаю. А про какие ты описания полей твердишь, так совсем не ясно... И что это за реляционные структуры - тоже непонятно. Ты же не знаешь как в конкретных СУБД данные хранятся - о чём тогда ты говоришь?

а ведь все очень просто: в РСУБД - ФИКСИРОВАННАЯ ДЛИНА ЗАПИСИ.
складывается она из максимальных размеров полей. почему фиксированная?
а как ты собираешься запись искать, если у тебя длины записей разные?
или у тебя где-то сидит отдельная структура, в которой записаны позиции
для записей? тут уж слово "неоптимально" не подойдет, тут надо другое
искать. :)
а куда ты денешься без описаний полей? и почему ты решил, что не знаю?
не знал бы - промолчал. :)

pavelvp

Создаётся впечатление, как будто только Каше так поступает :-)))
например? я с удовольствием послушаю
Префиксное сжатие индексов у всех нормальных СУБД. У нас есть. И никакой дурак не будт хранить повторяющиеся ключи.

у нас - это где? Linter? возможно, я не буду спорить, посмотрю, если найду.
серьезно? так вот и не будет? а куда он их денет, скажи на милость?
в структуре вида:

ключ1_записьN
ключ2_записьX
ключ3_записьY

ты полагаешь существует запись вида:

ключ2_записьA_записьB_записьC... ?

увы, ТАК не получится. а получится вот ТАК:

ключ1_записьX
ключ2_записьA
ключ2_записьB
ключ2_записьС
ключ3_записьY
это, естественно, при условии разрешении дублирования ключа.
в противном случае, ключ конечно только один, но и запись только одна.

pavelvp

А теперь результаты, которые я получил загружая не тупо, по-настоящему.
Т.е. результаты честного теста (не совсем честно, т.к. структура данных была потеряна):

что за ерунда насчет "структура данных была потеряна"? ничего там не потерялось, все на месте.

pavelvp

- Загрузка шла весьма шустренько - ничего удивительного, т.к. фактически шло "тупое" построение деревяхи с одним ключом.

нет. построение "плоской таблицы". абасалютно идентичной твоей. :)

pavelvp

- "оптимальный" размер файла cache.dat получился 208 мегов :-)))
Разница в 26 метров, от тех "неоптимальных" 234-х, получилась видимо за счёт отсутсвия 59 полей :-)

повторюсь - поля не пропали, они все есть. не выдумывай
я же сказал, структура - неоптимальна. колоссальный выигрыш на лобовом
переносе данных невозможен. выигрывается за счет выброса NULL.
кстати, было бы неплохо посмотреть, убрались ли концевые "," в данных
или все-таки болтаются в массиве. запусти, plz, ^%G и посмотри на него.

pavelvp

Что же я получил. Полное отсутствие структуры данных со всеми вытекающими и почти в 2 раза больший объём БД. Выигрышь только в скорости загрузки. И тот сомнительный... Нужно попробовать грузить в ЛИНТЕР тоже одной такой строкой.

"полное отсутствие структуры данных", надо же. будь так добр,
приведи, plz, размер исходного файла с данными и посмотри на концевые
разделители.
насчет загрузки в ЛИНТЕР - запросто, только сможешь ли потом выдергивать
поля в нужном виде? :)

pavelvp

Что опять я делал не так?

посмотрим. :)

С уважением. Сергей
11 май 06, 06:41    [2650408]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Sergei Obrastsov
а ведь все очень просто: в РСУБД - ФИКСИРОВАННАЯ ДЛИНА ЗАПИСИ.
складывается она из максимальных размеров полей. почему фиксированная?
а как ты собираешься запись искать, если у тебя длины записей разные?
или у тебя где-то сидит отдельная структура, в которой записаны позиции
для записей? тут уж слово "неоптимально" не подойдет, тут надо другое
искать. :)
а куда ты денешься без описаний полей? и почему ты решил, что не знаю?
не знал бы - промолчал. :)

Ага - а параметр резервирования места на странице для таблиц сделан для красоты, И карта распределения страниц в БД тоже. И всякие процедуры дефрагментации и сжатия

P.S. И еще ... ну не собирается pavelvp записи искать, вот хоть тресни и нигде лично у него "отдельная структура не сидит". Вот запросом сказать серверу, что ему нужно найти - он сделает, а искать записи по страницам не будет, открою страшную тайну почему ... потому что не сможет этого сделать, так же как и управлять "отдельной структурой", отвечающей за распределение заполнения данных по страницам. Вот такой вот еще один "недостаток" всех РСУБД для тех, кто даже настолько ленив, что не может взять в руки книжки и прочитать элементарные основы, а так же кодеров (матерых программеров), предпочитающих все делать самим.
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
11 май 06, 07:22    [2650446]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
ASCRUS
Ага - а параметр резервирования места на странице для таблиц сделан для красоты, И карта распределения страниц в БД тоже. И всякие процедуры дефрагментации и сжатия

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

ASCRUS

P.S. И еще ... ну не собирается pavelvp записи искать, вот хоть тресни и нигде лично у него "отдельная структура не сидит". Вот запросом сказать серверу, что ему нужно найти - он сделает, а искать записи по страницам не будет, открою страшную тайну почему ... потому что не сможет этого сделать, так же как и управлять "отдельной структурой", отвечающей за распределение заполнения данных по страницам. Вот такой вот еще один "недостаток" всех РСУБД для тех, кто даже настолько ленив, что не может взять в руки книжки и прочитать элементарные основы, а так же кодеров (матерых программеров), предпочитающих все делать самим.

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

тебе не кажется, что получается забавная картина: то вы с пеной у рта
уверяете меня, что "такое невозможно", "так не бывает" и "так не
хранится", но как только разговор заходит о конкретных вещах - прыг
в кусты - "а нам и не надо, у нас сервер думает"? вы уж, господа,
определитесь с направлением, ага. :)

С уважением. Сергей
11 май 06, 07:40    [2650464]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Sergei Obrastsov
mir
Маленький комментарий. Реляционная модель чисто логическая и не имеет отношения к физическим структурам и принципам хранения. Хорошо бы вам сразу на берегу это признать.

запросто. ну вот, признал. что изменилось? вот я смотрю, что в MySQL, в MS SQL и в Clarion размер БД почти одинаков. желающие могут полезть в Oracle, SyBase и иже с ними, и получить примерно такую же картину. выводы?
Изменилось (надеюсь) то, что вы признали свою ошибку.
Далее, аналогичный вопрос: выводы? Я лично не имею установленных на компе 5 СУБД, поэтому не могу проверить истинность ваших слов про равный размер БД. Это вообще очень сомнительно, так как даже в одной СУБД (MS SQL Server) размер одной и той же базы может существенно меняться в зависимости от SHRINKDATABASE, от настройки индексов и т.д. Но в любом случае, если не применяется сжатие, то минимальный объем данных и должен быть примерно одинаков, поскольку строка из L байт занимает L байт, а N m-байтных чисел занимают N*m байт, чудес-то не бывает. Или вы верите в магию?
Sergei Obrastsov
mir
И конкретные структуры хранения являются особенностями реализации конкретной РСУБД. И таковых множество. Хранение по строкам, да еще и с фиксированном их размером есть только один из подходов. Есть хранение по столбцам (см. Sybase IQ), есть IOT (Oracle), есть модель TransRelational. Да и "по строкам" хранять можно по разному.
Не ясно, почему вы с таким упорством говорите о "реляционных структурах" физического хранения, ведь такого понятия просто не существует.
я говорю, что при одинаковом подходе к логической структуризации данных для последующей обработки и хранения, получается примерно одинаковый объем хранимой информации. поэтому я позволяю себе
обобщать. что вам не нравится?
Если вы хотите говорить то, что только что сказали, то так и говорите. Но зачем же говорить про другое, про "реляционные структуры физического хранения", это просто неграмотно.
Sergei Obrastsov
а ведь все очень просто: в РСУБД - ФИКСИРОВАННАЯ ДЛИНА ЗАПИСИ. складывается она из максимальных размеров полей.
А ведь чуть раньше вы вроде признали, что это не так («ну вот, признал. что изменилось»). Выходит, не признал. Ваше упорство достойно лучшего применения. После того, как вам указали, что вы заблуждаетесь, и даже назвали несколько различных подходов к физическому хранению в РСУБД, вы снова повторяете эту чушь. Это такой специальный вид упрямства?
11 май 06, 07:57    [2650487]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
mir
Изменилось (надеюсь) то, что вы признали свою ошибку.

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

mir

случае, если не применяется сжатие, то минимальный объем данных и должен быть примерно одинаков, поскольку строка из L байт занимает L байт, а N m-байтных чисел занимают N*m байт, чудес-то не бывает. Или вы верите в магию?

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

Sergei Obrastsov
Если вы хотите говорить то, что только что сказали, то так и говорите. Но зачем же говорить про другое, про "реляционные структуры физического хранения", это просто неграмотно.

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

mir

Sergei Obrastsov
а ведь все очень просто: в РСУБД - ФИКСИРОВАННАЯ ДЛИНА ЗАПИСИ. складывается она из максимальных размеров полей.
А ведь чуть раньше вы вроде признали, что это не так («ну вот, признал. что изменилось»). Выходит, не признал.

где это я сказал "признаю, что в РСУБД отныне - ЗАПИСИ ПЕРЕМЕННОЙ ДЛИНЫ"? да ни в жисть я такого не признаю, врать - грешно. :)
признал, да только не то. надо было поинтересоваться "а что признал?" :)

mir

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

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

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

С уважением. Сергей
11 май 06, 08:36    [2650536]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Iura
Вот где Cache будет сильно пасовать, так это в расчетах. Если потребуется делать множество расчетов, система будет пасовать. Поскольку ей надо будет каждое число переводить в нормальную форму, вычислять, а потом запихивать ее опять в виде числа.

может и не стоило уже на это отвечать, тем более <Iura> куда-то запропастился, но не смог удержаться.

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

С уважением. Сергей
11 май 06, 08:52    [2650565]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
andy st
Member

Откуда:
Сообщений: 899
Sergei Obrastsov

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

лови
MSSQL2000
create table a (f1 varchar(1000),f2 varchar(1000))
go

create table b (f1 varchar(1000),f2 varchar(1000))
go

create table c (f1 varchar(1000),f2 varchar(1000))
go

set nocount on
declare @i integer
set @i = 0
while @i < 10000
begin
 insert into a	(f1,f2) values (null,null)
 insert into b	(f1,f2) values (replicate('x',100),replicate('x',100))
 insert into c	(f1,f2) values (replicate('x',1000),null)
 set @i=@i+1
end
--drop table a
select count(*) from a
select count(*) from b
select count(*) from c
exec sp_spaceused 'a'
exec sp_spaceused 'b'
exec sp_spaceused 'c'
set nocount off
drop table a
drop table b
drop table c
и результат
name	rows	reserved	data	index_size	unused
a	9940    136 KB	         120 KB	  8 KB  	8 KB

name	rows	reserved	data	index_size	unused
b	9972    2248 KB	        2224 KB	  8 KB	     16 KB

name	rows	reserved	data	index_size	unused
c	9919    11400 KB	11344 KB     8 KB  	    48 KB
11 май 06, 09:16    [2650623]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
andy st
name	rows	reserved	data	index_size	unused
a	9940    136 KB	         120 KB	  8 KB  	8 KB

name	rows	reserved	data	index_size	unused
b	9972    2248 KB	        2224 KB	  8 KB	     16 KB

name	rows	reserved	data	index_size	unused
c	9919    11400 KB	11344 KB     8 KB  	    48 KB

впечатляет. маленькое уточнение можно? у меня под рукой SQL сейчас нет,
поэтому я попрошу тебя: а можно ли повторить все это дело, но обращая
внимание на размер файла БД, а не на то, что он посчитал по полям?
если прав ты, то размер файла должен меняться. если прав я - то нет.
(понятное дело, нужно для каждого случая создавать новую базу, но
ведь это не сложно, ага?)

С уважением. Сергей
11 май 06, 09:29    [2650671]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Sergei Obrastsov
я вообще-то догадывался об этом, но все-равно спасибо, открыл, панимашь,
глаза. только вот что ты называешь "страницей", если не секрет? особенно
с учетом вышеупомянутого "резервирования места" на них.

Не помню, чтобы мы переходили на ты. А по существу - почему бы не почитать примитивных книжек, коих до чертиков, где все это расжевано по косточкам - и что такое страница и что такое сжатие БД и что такое дефрагментация таблиц, вместо того, чтобы выдавать свои фантазии и убогие познания РСУБД за действительность, проявив как минимум уважение к своим оппонентам в споре ? Или религия не позволяет ? Или мы такие умные, что и так все знаем и можем учить тех, кто с этим работает ? Знаете чем вы MUMPS-сты пока на этом форуме отличаетесь от РСУБД-шников - тем, что разглагольствуете о том, что не знаете и на чем не работаете, путая термины, сравнивая РСУБД с DBF-файлами, путаясь в понятиях физической и логической структуре данных, смешивая релляционную алгебру и SQL в одну кучу и поря прочую настоящую чушь. Я не помню, чтобы лично я рассуждал о принципах хранения данных в MUMPS/CACHE или с умным видом критиковал глобалы ... по простой причине, что я этого не знаю. Но ... если бы меня прижало посморить с вами, то первым бы делом я скачал и поставил Cache, прочитал входящую документацию, ознакомился с базовыми понятиями и принципами работы, провел серию тестов ... и только потом бы стал делать выводы и осторожно приступать к спору, что кстати и начал делать pavelvp, который сразу же наткнулся на несовпадение лозунгов и реальной действительности.
11 май 06, 09:43    [2650728]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MGR
Member

Откуда:
Сообщений: 536
Sergei Obrastsov
впечатляет. маленькое уточнение можно? у меня под рукой SQL сейчас нет,
поэтому я попрошу тебя: а можно ли повторить все это дело, но обращая
внимание на размер файла БД, а не на то, что он посчитал по полям?
если прав ты, то размер файла должен меняться. если прав я - то нет.
(понятное дело, нужно для каждого случая создавать новую базу, но
ведь это не сложно, ага?)


Я провел сравнение. Машина на которой есть сервер стоит рядом, но копипест не доступен. Поэтому описательно.
Каждый раз новая база (MS SQL)
Таблица имеет одно поле varchar(1000) и вставляется 100 000 строк.

Первый случай: вставляем replicate('X', 1000).
Размер базы вырос до 120Мб

Второй случай: вставляем replicate('X', 100).
Размер базы вырос до 13Мб

Третий случай: вставляем null
Размер вырос до 2Мб

Единственное непонятно - зачем я занимался проверкой того, в чем и так был уверен?
11 май 06, 09:56    [2650805]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
MGR
Первый случай: вставляем replicate('X', 1000).
Размер базы вырос до 120Мб
Второй случай: вставляем replicate('X', 100).
Размер базы вырос до 13Мб
Третий случай: вставляем null
Размер вырос до 2Мб
Единственное непонятно - зачем я занимался проверкой того, в чем и так был уверен?

наверное, чтобы убедить меня? :) ok, спасибо.
остается извиниться за свою уверенность, действительно VARCHAR поля
пишутся не на максимальную длину. SORRY, на будущее буду осторожнее
с выводами. :)

С уважением. Сергей
11 май 06, 10:14    [2650927]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Anton Demidov
Я немного выпал из обсуждения, за что прошу прощения.
Следуя ссылке ggv мы попадаем на доку по совсем свеженькой V5R4 (не знаю никого, у кого бы она уже стояла).
Впрочем, не важно.
Итак, номер один - лёгкость использования - читаем :
V5R4
In COBOL and C, varying-length character strings are represented as structures.
In C, varying-length character-string variables can also be represented by NUL-terminated strings. - везде бы так просто реализовали
...
CLOB varying-length character-string variables can be defined in all host languages except REXX, RPG/400, and COBOL/400.

Надеюсь, перевод не нужен? Или пространные объяснения о "простоте" сравнения двух строк VARCHAR на Коболе, которые на самом деле структуры?
На мой взгляд, представление VARCHAR'ов структурами правильно и естественно, а null terminated строками - нет. И это не проблемы сервера DB2. Хотя и странно, почему REXX/400 не читает CLOB'ы - под виндами-то он может.

Номер два: качество имплементации в БД (ладно, ладно, ожидая шквал возмущений от ggv и ко. перефразирую это в "особенности реализации")
Tips for using VARCHAR and VARGRAPHIC data types in databases
Там говорится о том, что VARCHAR это всё равно фиксированный CHAR плюс опциональный сегмент, за который вы заплатите дополнительным i/o

А вот это странно. Хотя, быть может, не так плохо, как кажется.
11 май 06, 10:15    [2650932]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MGR
Member

Откуда:
Сообщений: 536
Sergei Obrastsov
наверное, чтобы убедить меня? :) ok, спасибо.
остается извиниться за свою уверенность, действительно VARCHAR поля
пишутся не на максимальную длину. SORRY, на будущее буду осторожнее
с выводами. :)



Убедиться проще самому.
Я убедился году так в 98ом, когда после фокспро по привычке проектировал базу с char-ами. Ну и напроектировался, база распухла до 4Г, что тогда было достаточно много.
Простое изменение большинства описательных полей типа NAME, DESCR и пр. с char(80) на varchar(80) и т.д. позволило уместить ту же базу в 0.5Г.
11 май 06, 10:24    [2651005]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Sergei Obrastsov
andy st
name	rows	reserved	data	index_size	unused
a	9940    136 KB	         120 KB	  8 KB  	8 KB

name	rows	reserved	data	index_size	unused
b	9972    2248 KB	        2224 KB	  8 KB	     16 KB

name	rows	reserved	data	index_size	unused
c	9919    11400 KB	11344 KB     8 KB  	    48 KB

впечатляет. маленькое уточнение можно? у меня под рукой SQL сейчас нет,
поэтому я попрошу тебя: а можно ли повторить все это дело, но обращая
внимание на размер файла БД, а не на то, что он посчитал по полям?
если прав ты, то размер файла должен меняться. если прав я - то нет.
(понятное дело, нужно для каждого случая создавать новую базу, но
ведь это не сложно, ага?)

С уважением. Сергей

К сожалению, с базой сделать сложнее. В первом случае - размер таблицы 120 KB, насколько я помню - в MSSQL нельзя задать размер базы таким мелким
ну а столбец reserved - это и есть физический размер данных. Так что, разница заметна.
11 май 06, 10:27    [2651027]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
MGR
Убедиться проще самому.
Я убедился году так в 98ом, когда после фокспро по привычке проектировал базу с char-ами. Ну и напроектировался, база распухла до 4Г, что тогда было достаточно много.
Простое изменение большинства описательных полей типа NAME, DESCR и пр. с char(80) на varchar(80) и т.д. позволило уместить ту же базу в 0.5Г.

логично, если есть необходимость сравнивать. в MS SQL я всегда использал
varchar, особо не задумываясь. но мои базы никогда и не отличались
объемностью, так что тут как-то и не поэскпериментируешь. обрати внимание,
что в своем тесте я, конечно, использовал именно varchar. :)

С уважением. Сергей
11 май 06, 10:50    [2651162]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 15 [16] 17 18 19   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить