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

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

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

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

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

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

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? возможно, я не буду спорить, посмотрю, если найду.
серьезно? так вот и не будет? а куда он их денет, скажи на милость?
в структуре вида:


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


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

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

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

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

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

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

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

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

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

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

pavelvp
Что опять я делал не так?
посмотрим. :)

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

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

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

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

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

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

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

mirИзменилось (надеюсь) то, что вы признали свою ошибку.

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

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

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

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

уф... а как "грамотно"?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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