Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>Такая сериализация при определенных условиях будет значительно эффективнее чем XML или JSON.
AVK>При каких условиях?
При количестве записей в таблицах больше 10.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>Такая сериализация при определенных условиях будет значительно эффективнее чем XML или JSON.
AVK>При каких условиях?
Например в нормальной БД данные хранятся в страницах. Излишки могут занимать много места когда небольшой объем данных. Если же сначала сериализовать в List а затем зная размер для каждой таблицы можно просто выделить место в файле. Или перезаписывать в такое хранилище при большом количестве пустого места.
При этом не будет никаких лишних мест. И будет занимать меньше места даже при малых объемах.
Это будет структурированное IStorage.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>>> Смысл такой сериализации когда сериализуется массив. AVK>>>> Ты сам то понял что сказал? S>>> Наборы данных. Так пойдет? AVK>>Нет. Смысл фразы все равно непонятен. S> Например Запрос или результат линка.
Ты не пьян, случаем?
AVK>>Т.е. то, что для передачи типичной посылки в сотню байт придется гонять десятки и сотни килобайт минимальной БД, и на каждую посылку поднимать коннект к новой БД не из пула тебя не пугает, а 30-40% оверхеда по объему и копейки по процессору у XML это ужас-ужас? S> Моя минимальная БД
То есть предлагается еще и спецБД написать?
S>Да и предначзначена такая БД не для передачи 2 трех строк. А например тысяч.
Ну и как будет это выглядеть? Если строк меньше 1000 — передаем одним способом, а если больше — другим?
AVK>>Нормально, если в DOM весь XML не грузить (XMLSerializer, если что, не грузит). А еще лучше через Protobuf или его аналоги. S> А зачем лишние мегабайты таскать?
Нет никаких лишних мегабайтов, особенно во втором случае.
AVK>>И как ты БД в 1С открывать будешь? Через ADO? S> Да.
И этот человек плачется про оверхед XML. Пока ты через ADO будешь БД открывать, даже тормозной Remoting/SOAP успеет раз десять туда/сюда передать данные.
AVK>>Для переноса — низачем. И БД тоже не нужна. S> Это тве личное мнение.
А у тебя, надо думать, общепринятая точка зрения? Почему тогда бред, который ты описываешь, в природе не встречается, зато ужас-ужас ака ХМЛ — сплошь и рядом?
S> Если сжать XML то он жмется раз в 10.
В 10 не жмется. Сжать, опять же, никто не мешает без всяких БД.
S> Размер такой БД будет меньше еще раз в 100.
А давай ты попробуешь сам, а потом сказки про 100 раз рассказывать будешь.
AVK>>Какое такое описание полей и чем оно лучше XSD? S>Оно не лучше
Тогда и твоя мегаидея не лучше.
S>, оно берет лучшее из XML и бинарной сериализацией.
Что именно?
S> А тем что например такая структура
S><CatalogObject.Контрагенты> S> <IsFolder>true</IsFolder> S> <Ref>2eca11b5-f2d4-46e4-8b86-5d4579c64a64</Ref> S> <DeletionMark>false</DeletionMark> S> <Parent>00000000-0000-0000-0000-000000000000</Parent> S> <Code>000016 </Code> S> <Description>ПОСТАВЩИКИ</Description> S> <Комментарий/> S> </CatalogObject.Контрагенты> S>В таблице будет занимать намного меньше места.
А в формате Protobuf?
S> Кроме того проще управлять
Чем проще?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, Serginio1, Вы писали:
S> Например в нормальной БД данные хранятся в страницах.
Ага. И fill factor обычно используется равным 0.5. Это означает, что избыточность минимум в два раза. На любом объеме данных.
S>Если же сначала сериализовать в List а затем зная размер для каждой таблицы можно просто выделить место в файле.
И зачем тут БД?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>>>>> Смысл такой сериализации когда сериализуется массив. AVK>>>>> Ты сам то понял что сказал? S>>>> Наборы данных. Так пойдет? AVK>>>Нет. Смысл фразы все равно непонятен. S>> Например Запрос или результат линка.
AVK>Ты не пьян, случаем?
Уже 6 лет не пью и фитнесом занимаюсь. AVK>>>Т.е. то, что для передачи типичной посылки в сотню байт придется гонять десятки и сотни килобайт минимальной БД, и на каждую посылку поднимать коннект к новой БД не из пула тебя не пугает, а 30-40% оверхеда по объему и копейки по процессору у XML это ужас-ужас? S>> Моя минимальная БД
AVK>То есть предлагается еще и спецБД написать?
А чего её писать то. Там все элементарно. S>>Да и предначзначена такая БД не для передачи 2 трех строк. А например тысяч.
AVK>Ну и как будет это выглядеть? Если строк меньше 1000 — передаем одним способом, а если больше — другим?
Я в предыдущей ветке писал, как можно отказавшиь от страниц, записать таблицу в стрим без лишнего места.
AVK>>>Нормально, если в DOM весь XML не грузить (XMLSerializer, если что, не грузит). А еще лучше через Protobuf или его аналоги. S>> А зачем лишние мегабайты таскать?
AVK>Нет никаких лишних мегабайтов, особенно во втором случае.
Кстати а как данные Protobuf хранит? AVK>>>И как ты БД в 1С открывать будешь? Через ADO? S>> Да.
AVK>И этот человек плачется про оверхед XML. Пока ты через ADO будешь БД открывать, даже тормозной Remoting/SOAP успеет раз десять туда/сюда передать данные.
У меня другие объемы данных. Например обновить 4 миллиона записей меньше 2 минут занимает.
AVK>>>Для переноса — низачем. И БД тоже не нужна. S>> Это тве личное мнение.
AVK>А у тебя, надо думать, общепринятая точка зрения? Почему тогда бред, который ты описываешь, в природе не встречается, зато ужас-ужас ака ХМЛ — сплошь и рядом?
А тем, что нет других механизмов. Вот например появился Protobuf будут его использовать. S>> Если сжать XML то он жмется раз в 10.
AVK>В 10 не жмется. Сжать, опять же, никто не мешает без всяких БД.
S>> Размер такой БД будет меньше еще раз в 100.
AVK>А давай ты попробуешь сам, а потом сказки про 100 раз рассказывать будешь.
Я это проделывал многократно. Пример тому можно посмотреть как увеличится БД. Да и просто посчитать реальный объем данных в БД несложно.
AVK>>>Какое такое описание полей и чем оно лучше XSD? S>>Оно не лучше
AVK>Тогда и твоя мегаидея не лучше.
S>>, оно берет лучшее из XML и бинарной сериализацией.
AVK>Что именно?
S>> А тем что например такая структура
S>><CatalogObject.Контрагенты> S>> <IsFolder>true</IsFolder> S>> <Ref>2eca11b5-f2d4-46e4-8b86-5d4579c64a64</Ref> S>> <DeletionMark>false</DeletionMark> S>> <Parent>00000000-0000-0000-0000-000000000000</Parent> S>> <Code>000016 </Code> S>> <Description>ПОСТАВЩИКИ</Description> S>> <Комментарий/> S>> </CatalogObject.Контрагенты> S>>В таблице будет занимать намного меньше места.
AVK>А в формате Protobuf?
А можешь привести этот формат? S>> Кроме того проще управлять
AVK>Чем проще?
Вот я например не нашел описания хранения данных Protobuf. А вот например пользоваться Access знают все. БД в простейшем случае это набор таблиц зранящих записи в виде структур.
Исключения составляют Блоб таблицы.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> Например в нормальной БД данные хранятся в страницах.
AVK>Ага. И fill factor обычно используется равным 0.5. Это означает, что избыточность минимум в два раза. На любом объеме данных.
S>>Если же сначала сериализовать в List а затем зная размер для каждой таблицы можно просто выделить место в файле.
AVK>И зачем тут БД?
Еще раз БД это набор таблиц. Называй это как хочешь. Каждый тип хранится в своей таблице. Типы имеющие потомки хранятся в виде структуры тип (номер таблицы) и номер записи в таблице.
Как по твоему должно называться такое хранилище?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>То есть предлагается еще и спецБД написать? S> А чего её писать то. Там все элементарно.
AVK>>Ну и как будет это выглядеть? Если строк меньше 1000 — передаем одним способом, а если больше — другим? S> Я в предыдущей ветке писал, как можно отказавшиь от страниц, записать таблицу в стрим без лишнего места.
Ну то есть там и БД не БД. И чем это отличается от Protobuf?
AVK>>Нет никаких лишних мегабайтов, особенно во втором случае. S> Кстати а как данные Protobuf хранит?
http://en.wikipedia.org/wiki/Protocol_Buffers и далее по ссылкам.
AVK>>А у тебя, надо думать, общепринятая точка зрения? Почему тогда бред, который ты описываешь, в природе не встречается, зато ужас-ужас ака ХМЛ — сплошь и рядом? S> А тем, что нет других механизмов.
А почему их нет? Неужели потому что никому твоя гениальная идея не пришла на ум?
S> Вот например появился Protobuf будут его использовать.
Он давно появился. Но это ж не БД!
AVK>>А давай ты попробуешь сам, а потом сказки про 100 раз рассказывать будешь. S> Я это проделывал многократно.
И какую БД ты использовал для передачи данных?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, Serginio1, Вы писали:
AVK>>И зачем тут БД? S> Еще раз БД это набор таблиц.
A database is an organized collection of data. The data is typically organized to model relevant aspects of reality (for example, the availability of rooms in hotels), in a way that supports processes requiring this information (for example, finding a hotel with vacancies).
Ключевой момент я выделил жирным.
S> Называй это как хочешь.
Что "это"?
S> Каждый тип хранится в своей таблице.
А что такое таблица?
S>Как по твоему должно называться такое хранилище?
Просто структурированное хранилище.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>>>А давай ты попробуешь сам, а потом сказки про 100 раз рассказывать будешь. S>> Я это проделывал многократно.
AVK>И какую БД ты использовал для передачи данных? http://1c.proclub.ru/modules/mydownloads/personal.php?cid=115&lid=2019
исходники и примеры простенькой Иерархической БД. Все таблицы хранятся в одном потоке (TFileStream или аналоге TMemoryStream). Реализованы следующие виды таблиц: простые, подчиненные ввиде двухнаправленных списков и Стрим и блоб таблицы
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>исходники и примеры простенькой Иерархической БД. Все таблицы хранятся в одном потоке (TFileStream или аналоге TMemoryStream). Реализованы следующие виды таблиц: простые, подчиненные ввиде двухнаправленных списков и Стрим и блоб таблицы
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>И зачем тут БД? S>> Еще раз БД это набор таблиц.
AVK>
AVK>A database is an organized collection of data. The data is typically organized to model relevant aspects of reality (for example, the availability of rooms in hotels), in a way that supports processes requiring this information (for example, finding a hotel with vacancies).
AVK>Ключевой момент я выделил жирным.
S>> Называй это как хочешь.
AVK>Что "это"?
S>> Каждый тип хранится в своей таблице.
AVK>А что такое таблица?
Ну можно представить в виде IList<T>
S>>Как по твоему должно называться такое хранилище?
AVK>Просто структурированное хранилище.
Хорошо, так чем плохо структурированное хранилище для целей сериализации?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>исходники и примеры простенькой Иерархической БД. Все таблицы хранятся в одном потоке (TFileStream или аналоге TMemoryStream). Реализованы следующие виды таблиц: простые, подчиненные ввиде двухнаправленных списков и Стрим и блоб таблицы
AVK>И чем это лучше того же http://ravendb.net/ ?
Да ничем. Просто такое структурированное хранилище прекрасно подходит для целей сериализации, занимая минимальное количество кода, а значит может быть встроено в системные сборки. На дженериках это хранилище вообще пишется на раз.
Кстати спасибо за ссылки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>исходники и примеры простенькой Иерархической БД. Все таблицы хранятся в одном потоке (TFileStream или аналоге TMemoryStream). Реализованы следующие виды таблиц: простые, подчиненные ввиде двухнаправленных списков и Стрим и блоб таблицы
AVK>И чем это лучше того же http://ravendb.net/ ? http://ravendb.net/docs/intro/ravendb-in-a-nutshell
Данные в RavenDB хранится без схемы как документы JSON
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>Просто структурированное хранилище. S> Хорошо, так чем плохо структурированное хранилище для целей сериализации?
Хранилище? Наверное тем, что спроектировано для хранения, а не для передачи данных.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
_>>Ты забыл ещё JSON! Их тоже вроде 2-3 штуки!!! публичных должно быть, сам видел AVK>Я не забыл. Во-первых в самом фреймворке их вроде нет (MVC вроде сейчас как то отдельно), во-вторых это текстовый формат.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>При каких условиях? S>> При количестве записей в таблицах больше 10.
AVK>Откуда взята эта цифра?
Нужны затраты на описание полей, размещение таблиц. В среднем в классе около 10 полей. То есть занимаемый размер 10 записей в таком хранилище будет около 10 записей с помощью BF
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>И чем это лучше того же http://ravendb.net/ ? S>> Да ничем.
AVK>Значит велосипед.
Ну с этой точки зрения любая программа это велосипед. Опять же я говорю о Структурированном хранилище для сериализации и десериализации.
Опять же написать её не проблема в NET через рефлекшн. S>> Просто такое структурированное хранилище прекрасно подходит для целей сериализации
AVK>Так бери да пользуйся, меппер классов на рейвен идет в комплекте, embedded версия вроде тоже была.
А толку? Для себя я могу сделать что угодно. Но вот работаю то я не сам с собой. А отгадай какой самый часто встречаемый формат для обмена данных? Ну конечно ёксель.
Затем идут текстовые файлы (CSV), вэб сервисы (XML).
А вот совместное использование возможно только тогда когда такой механизм будет открытым и встроенным в системные сборки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Просто структурированное хранилище. S>> Хорошо, так чем плохо структурированное хранилище для целей сериализации?
AVK>Хранилище? Наверное тем, что спроектировано для хранения, а не для передачи данных.
Что бы передать данные ты должен сохранить в поток. Поток это тоже хранилище только не структурированное.
и солнце б утром не вставало, когда бы не было меня
Ты сам то понял что сказал?
