Здравствуйте, computer20, Вы писали:

C>Здравствуйте, Sinclair, Вы писали:

S>>А именно то, что невозможно прочитать меньше одного кластера. Поэтому желательно делать так, чтобы записи таблицы были выравнены по границам кластеров, и чтобы все операции чтения и записи минимизировали количество задействованных страниц.

C>Согласен: разнесение записи на два кластера снижает производительность (если ты это хотел сказать — пришлось за тебя додумывать).
Если тебе приходится тут еще и додумывать, то я пас. Извини, я сразу тебе написал русским по белому, что невыровненные записи снижают производительность.

C>Вопросы:
C>достаточно ли современного ОСУ, чтобы расположить там большинство БД целиком?
Что такое ОСУ? Память? Конечно же недостаточно. Потому, что есть операции, для которых потребуется хранить промежуточные результаты, и потребности СУБД по памяти превышают физический объем данных. См. Гарсиа-Молина, Системы Баз Данных. Полный Курс.
Кстати, хочу напомнить, что хранение базы в volatile memory применимо в очень малом количестве случаев. Обеспечение требований сохраняемости (буква D в слове A.C.I.D) с приемлемой производительностью, даже в случае 100% кэширования данных приведет к страничной организации.

C>какие изменения претерпевает ваше возражение в случае замены винта флэш-памятью
C>(вне зависимости от возможности расположить всю БД целиком в ОЗУ)?
Никакие. Скорость линейного чтения/записи флэш-памяти слишком низка чтобы составить заметную конкуренцию HDD. А себестоимость мегабайта — слишком велика.
Возможно, развитие всяких PRAM и прочих высокоскоростных устройств произвольного доступа смягчит существующие требования, и можно будет пересмотреть устройство СУБД. Но я вовсе не уверен, что ISAM форматы вдруг зарулят даже в этом случае.

S>>Оттуда, что перемещение одной записи потребует изменения недетерминированного количества записей в других таблицах. Стоимость этой операции превышает всякие разумные пределы.
C>Согласен. Откуда следует большое КОЛИЧЕСТВО дыр, в результате чего потребуется перенести такое же количество записей,
C>чтобы их заполнить?
Из того, что записи регулярно удаляются. Для write-only баз (типа логов) это еще приемлемо, но это слишком частный случай. Главный вопрос — когда выполнять дефрагментацию? Синхронно с удалением? Неприемлемо по производительности.

В общем, все же очень рекомендую сначала прочитать учебники.

Здравствуйте, fmiracle, Вы писали:

F>Кстати я забыл — интел и моторола — это социалистические корпорации или феодальные?
F>Я помню, что Микрософт, по твоим утверждениям, делает поганый софт, посольку является капиталистической....

Жаль гугль аппаратурой не занимается, люди говорят там коммунизм

Здравствуйте, Sinclair, Вы писали:

S>Естественно, сложность одинакова. Рекомендую прочитать в моем посте следующее предложение за тем, на которое ты ответил.

То есть ты твердо уверен, что найти ошибку в списке координат так же просто, как в нарисованной карте?
Во время программирования код читают на порядок чаще, чем пишут. Нельзя написать программу за один присест, если конечно это не тривиальный SQL-запрос.

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, Left2, Вы писали:

>>>>кластер из кучи дешовых писюков тебе не подойдет?

C>>>Велики затраты на его программирование.

L>>По сравнению с затратами на создание принципиально нового железа — сущие копейки.

C>Надеюсь, что разработку железа выполнят в т.ч.и intel, motorola, etc

Не надейся, не выполнят. Пока ты ни одного человека на форуме убедить не смог, что это нужно делать. Это уже о чем то говорит.

C>>>1. описываемое xML ограничивается деревьями, BAF кодирует и графы
dmz>>При помощи XML можно задать любой граф. Вы хотя бы это понимаете?

C>Опишите на нем 4 сущности <item> вложенных одна в другую с образованием кольца.

один из вариантов, inspired by Graphviz (тоже такого не знаете, да? между тем, полезная вещь и снимает головную боль при визуализации графов и диаграмм на вебе, в частности):

<graph>
<node id="A"/>
<node id="B"/>
<node id="C"/>
<node id="D"/>
<rib from="A" to="B" weight="1"/>
<rib from="B" to="C" weight="1"/>
<rib from="C" to="D" weight="1"/>
<rib from="D" to="A" weight="1"/>
</graph>

можно и по другому, масса вариантов.

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, creatman, Вы писали:

C>>>в таком разрезе речь идет о коммуникации в формате xML и BAF (или возможно какого-л другого формата).
C>>>1. описываемое xML ограничивается деревьями, BAF кодирует и графы

C>>а вы покажите где такое может понадобится относительно разработки UI например?

C>разбейте поверхность 3D-фигуры на треугольники

Ну давайте закончим на том, что XML позволяет графы описывать, как вам уже говорили.
Кстати для 3D поверхностей файл вида:
x1 y1 z1
x2 y2 z2
x3 y3 z3
....

придуманный лет так 30 а то и больше тому назад используется очень широко и по сей день, так что BAF в лес.

C>>>2. вопрос передачи и исполнения xML и BAF поднимает в первую очередь вопрос о соотношении преимуществ SMP,MPP машин и кластеров. Упаковывать в текст, передавать по меж-процессорным линкам, распаковывать xML менее разумно, чем передавать бинарную информацию — отсюда и координаты {PID,segment,displacement,offset}. Возможно какой-л другой бинарный формат
C>>>окажется лучше, но пока мы обсуждаем эту производную межпроцессорной коммуникации.

C>>Разговор шел (как я понял покрайней мере) об UI. ... И пользователю гораздо проще с текстом работать чем с файлом бинарным.

C>работать — это что делать? создавать текст в текстовом редактере? генерировать прогой?

И то и другое.

C>проще — это только создать или еще и скормить визуализирующей программе в реальном времени? полуть от растеризирующей проги
C>ранее введенные данные (не дублировать же в своих структурах, или получив в xml — не воссоздавать не структуры)?

Не вижу, в где тут проблема?

C>попытка изменять xml-описание и видеть на экране требует новой прокладки — по сравнению с изменением baf в видео-памяти.

Допустим. Чему это мешает? Если вы предлагаете городить целый компьютер как альтернативу, программной прокладки, которая в реальном времени будет подгружать данные из XML, то где тут смысл?

>>И кстати томуже пользователю будет проще читать файл в котором не граф а дерево.

C>согласен. только не всегда схема бывает деревом — иногда бывают замкнутые контуры.

См. выше.

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, creatman, Вы писали:

C>>>>А вы случайно не из тех, кто в институтах жопу просиживает за гос. счет и мало что полезного стране делает? (нивкоем случае не хачу никого тут обидеть).

AVK>>>Он же ясно написал — у него главная проблема в российском софтостроении это недофинансирование. У тебя еще вопросы есть?

C>>зачот!

C>Я бы добавил: недофинансирование не только софтостроения. Недофинансирование физиков лишает их возможности нанять программистов, т.е. недофинансирование одних отраслей влечет нехватку средств в других.

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

Куда делись гранты, на полезные и интересные работы? Не нужно рассказывать, что все чего вам не хватает это софт. Учитывая ваш уровень презентования идей, тебе ИМХО нужно копать в другом направлении.

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, creatman, Вы писали:

C>>>итак, "многая" (большая) масса людей обладает вполне конкретными (вероятно даже измеримыми) характеристиками.
C>>>Давайте примем это за отправную точку.
C>>>И с этой точки зрения будем оценивать язык.
C>>Какой язык... основная масса людей с мобильным телефоном то разобирается с трудом, а вы хотите их языку учить.

C>с примитивными функциями разбирается. с "двумя присваиваниями", надеюсь, будет также.

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

C>Товаришь, отделяйте проц от BAL. Давайте в этой теме оставаться в рамках "двух присваиваний"

Ну два присваивания это очень жостко. Давайте хоть восемь команд введем. За вас это уже придумали и назвали его более осмысленно Brainfuck


C>>>В вашем рассуждении о простоте Java отсутствует предыдущее звено: критерий простоты.
C>>>Давайте его выберем каким-н объективным, измеряемым.
C>>>Например, поведение масс при столкновении с таким языком — вполне надежный критерий.

C>>Ага, давайте тогда уже рассматривать не массу: врачи, психологи, художники, а ИТ специалисты и посмотрим статистику. Это самая объективная оценка.

C>Самая здесь неуместно. Это желаемая оценка. Вам просто не хочется принимать во внимание всех других.

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

>>Мне почемуто все больше и больше кажется что вы так и не смогли осилить Java

C>Логически не корректно — я никогда не пытался это сделать.

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

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

Из описанного тобой:

C>идимо речь пойдет об итерациях по этой матрице.
C>В for-ах и while-ах он будет изменять указатель на запись (положим, что у него записи, а не на элементы массива), беря его из полей ссылочного типа, и изменять значение полей записи, на которую указатель ссылается. for-ы, while-ы, указатель и присваивание — это он сможет одолеть, но не более (никаких библиотек, никаких входных-выходных текстовых форматов — обращение сразу к структурам в ОЗУ).

Нет ну я понимаю что по образованию ты физик, но ты не соотноси свой уровень и уровень познаний врача или темболее юриста. твои ссылки, указатели и структуры в ОЗУ это вобще кашмарный сон врача. Люди понимаешь с таблицами в Excel с трудом разбираются по книжкам, а ты тут городишь про структуры и указатели.


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

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, creatman, Вы писали:

C>>Для разработки систем любого уровня и качества

C>еще один параметр потерян — "с использованием рабочей силы любого качества", тогда бы я с вами согласился

Очевидно что сила любого качества это понятие абсолютное, а абсолютных решений не бывает.

>>внятных критериев по которым его нужно менять пока не получил.

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

>>>>чтобы это средство разговаривало с ним на его языке
C>>Какие у вас там проблемы возникают? Чего вы там с чем соединить не можите?

C>В части "соединения" пока ничего. Готовлюсь к будущему (к тому, чтобы избежать программировать на MPI,PVM,
C>перекодировок формата для рендеринга для совмещения с другими прогами).

Да вы просто молодец, чтобы избежать программирования на MPI и PVM вы придумали аж свой компьютер. Могу вас разочеровать, готовтесь к худшему и учите MPI, PVM и чего вам там еще нужно, так как ваш компьютер с 99% вероятности не будет сделан никогда и никем, а если и будет то в очень далеком и страшном будущем.

C>---

>>Поделитесь с народом, всетаки не дураки тут сидят, может чем поможем?

C>Вот текущая проблема (не обижайтесь за повтор — в частности и ее тоже я ее пытался решить в html60):
C>есть персонал, который знает только sql и html (ну xml/xsl, если ему объяснить).
C>Как автоматизировать 1500 человек, если известно, что хранения информации в базе и тегов для отображения ее в браузере хватает.
C>Полуть рекордсет из базы на php,perl и обрамление тегами не могут (проверено).
C>Этот вопрос также поднимался (помоему, в теме про html60), кроме MS SQL Server + xmlsql бридж
C>(если я правильно понял, это sqlxml.msi, он же сервис пак 3) никаких других предложений не прозвучало.

Может я проблему не понял.
Я увидел задачу абстрактно вот так:
Спроектировать базу, ну например 3 месяца на специалиста, поднять сервер. наколбасить формочки для каждого типа рабочих мест: ну формочки колбасить наверно могут ваши специалисты, за 3 месяца управятся. Написать для каждой формочки SQL запросы к базе ну еще грубо говоря 3-4 человеко/месяца на специалиста. А далее поддержка. Это я конечно грубо оценки привел, но по мне так задача решаемая даже одним специалистом за 1 год, ну пусть 1.5 года. Надеюсь у вас он не один.

Для более корректной оценки конечно нужно более конкретно задачу описать.

P.S. Супер компьютер для этих целей посылаем в лес.

Здравствуйте, AndreiF, Вы писали:
AF>То есть ты твердо уверен, что найти ошибку в списке координат так же просто, как в нарисованной карте?
Нет. Не твердо.
AF>Во время программирования код читают на порядок чаще, чем пишут. Нельзя написать программу за один присест, если конечно это не тривиальный SQL-запрос.
Хороший поинт.
Поясняю про карту: всё зависит от того, как подан этот "список координат". Если это что-то типа HPGL представления, то конечно же его будет ни писать ни читать не удобно. Но ведь в отличие от карты, текстовое представление позволяет использовать различную группировку, выделение отступами, ссылки друг на друга и т.п. Ты уверен, что на глаз сможешь увидеть на карте ошибку позиционирования элемента? А вот в тексте ты точно увидишь, совпадают координаты с правильными или нет. Ты уверен, что нельзя сделать IDE для картографии, которая будет, к примеру, показывать графические Hint-ы при наведении мышки на определение графического примитива?

Вот тебе еще повод задуматься: сейчас есть масса средств визуального проектирования UI. А что такое UI как не та же карта, только достаточно сложная? Ну так вот все программисты UI, кого я знаю, используют в 99% текстовое представление — будь это HTML или WinGUI. Потому, что оно позволяет точно контролировать свойства объектов. А визуальное представление используется для контроля получающегося результата. Как я и говорил — восприятие графической информации быстрее.

Здравствуйте, computer20, Вы писали:
C>Вносят данные в формы. В этих же формах часть данных из БД.
C>Ничего принципиально интересного они не делают: принимают решения (черт, как сильно сказал) на основе одних данных и вбивают другие. Достаточно много возни и на одно клиентское место (точнее, один его тип, но в рамках типа всего несколько человек),
C>а на полутора тысячах пользователей набегает очень много отчетов-форм. Вводимые данные либо текстовые строки (реже), либо точные числа (чаще).
Купите cебе InfoPath, MS SQL Server, MS SQL Reporting Services. Не нужно писать все эти формы на "алгоритмическом языке программирования". Специализированные средства придуманы достаточно давно. Никакой специальной аппаратуры или языка запросов для этого не требуется.

Здравствуйте, computer20, Вы писали:
C>Возможна ли в других форматах ситуация, когда данные располагаются так, что приходится часто двигать головку?
В страничном формате — практические нет, т.к. данные кластеризованы в страницы, а страницы — в экстенты. В итоге, скорость подкачки данных в память близка к теоретической пропускной способности HDD->RAM. Помимо этого, кэш-менеджеры промышленных СУБД поддерживают очередь подкачки таким образом, чтобы читать как можно более длинные последовательности страниц подряд. Это снижает вероятность лишних чтений.
C>Каков самый судший случай для какого-н признаваемого вами формата (признаваемого в качестве хорошего)?
Самый худший случай — это банальное линейное чтение в эксклюзивном режиме. Точнее, для страничного формата этот случай не сильно хуже, чем случайный доступ к данным, но накладные расходы на синхронизацию/транзакции/заголовки таблиц и записей больше, чем в случае ISAM файла. Только в этом случае ISAM формат имеет шанс выиграть, благодаря уменьшению количества прочитанных страниц и высокой вероятности последовательного чтения (если сканируемый файл сам по cебе не слишком фрагментирован).

Здравствуйте, FR, Вы писали:

F>>Кстати я забыл — интел и моторола — это социалистические корпорации или феодальные?
F>>Я помню, что Микрософт, по твоим утверждениям, делает поганый софт, посольку является капиталистической....

FR>Жаль гугль аппаратурой не занимается, люди говорят там коммунизм

Супер!

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

Итак, первый подход (пример ниже) требует разбора ВСЕГО текста, для нахождения того, с какими узлами связан данный узел.
Это проигрывает второму варианту (его пример ниже).
.>

.><doc>
.>    <items>
.>        <item id="i1">1</item>
.>        <item id="i2">2</item>
.>        <item id="i3">3</item>
.>        <item id="i4">4</item>
.>    </items>
.>    <links>
.>        <link from="i1" to="i2" />
.>        <link from="i2" to="i3" />
.>        <link from="i3" to="i4" />
.>        <link from="i4" to="i1" />
.>    </links>
.></doc>
.>

Следующий вариант мало того, что ограничивается одной связью, так еще и является практически текстовой копией бинарного baf-формата. Так зачем, спрашивается, использовать текст, если бинарный формат делает то же самое, и не трубует парсинга.

.>

.><items>
.>    <item id="i1" ref="i2">1</item>
.>    <item id="i2" ref="i3">2</item>
.>    <item id="i3" ref="i4">3</item>
.>    <item id="i4" ref="i1">4</item>
.></items>
.>

Здравствуйте, Sergey J. A., Вы писали:

SJA>Здравствуйте, computer20, Вы писали:

C>>в таком разрезе речь идет о коммуникации в формате xML и BAF (или возможно какого-л другого формата).
C>>1. описываемое xML ограничивается деревьями, BAF кодирует и графы

SJA>RDF, основанный на XML запросто описывает графы.
SJA>http://www.w3.org/RDF/


Он является практически текстовой копией бинарного baf-формата. Так зачем, спрашивается, использовать текст, если бинарный формат делает то же самое, и не трубует парсинга.

Здравствуйте, computer20, Вы писали:

C>>>в таком разрезе речь идет о коммуникации в формате xML и BAF (или возможно какого-л другого формата).
C>>>1. описываемое xML ограничивается деревьями, BAF кодирует и графы

SJA>>RDF, основанный на XML запросто описывает графы.
SJA>>http://www.w3.org/RDF/

C>Он является практически текстовой копией бинарного baf-формата. Так зачем, спрашивается, использовать текст, если бинарный формат делает то же самое, и не трубует парсинга.

Логическая ошибка п.1 говорит о невозможности описания XML-ем графов. Существование RDF является опровержением п.1
А вообще, мне легче читать/править тексторые данные, а не бинарные.

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, Sergey J. A., Вы писали:

SJA>>Здравствуйте, computer20, Вы писали:

C>>>в таком разрезе речь идет о коммуникации в формате xML и BAF (или возможно какого-л другого формата).
C>>>1. описываемое xML ограничивается деревьями, BAF кодирует и графы

SJA>>RDF, основанный на XML запросто описывает графы.
SJA>>http://www.w3.org/RDF/


C>Он является практически текстовой копией бинарного baf-формата. Так зачем, спрашивается, использовать текст, если бинарный формат делает то же самое, и не трубует парсинга.

Сказали-же, с текстовым файлом проще работать.

Здравствуйте, computer20, Вы писали:



C>Следующий вариант мало того, что ограничивается одной связью, так еще и является практически текстовой копией бинарного baf-формата. Так зачем, спрашивается, использовать текст, если бинарный формат делает то же самое, и не трубует парсинга.

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

C>что такое простите baf формат? у кого не спрошу никто не слышал... в гугле набираю, нифига нет... может быть это C>baf является бинарной копией xml?

Бинарный XML — это уже баян, над ним давно работают: http://en.wikipedia.org/wiki/Binary_XML
Более того, есть уже пробные имплементации, в частности, есть имплементации XML RPC, которые используют (какой-то?) bixml.

К тому-же, есть ASN.1 — уже невесть сколько лет, под двадцать, где-то.

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

Видимо, медленное продвижение bXML и забвение ASN.1 не в последнюю очередь связаны с тем, что процессорные мощности и каналы сейчас настолько дешевы, что собирание крох в виде использования бинарных протоколов просто себя не окупает, а принимая во внимание все связанные с этим сложности — однозначно убыточные. Дешевле пожать тот-же самый XML и отдать его так.