BAL - Новый усовершенствованный язык запросов,
предназначенный для обработки в базе данных деревьев.
Формат файлов базы данных - BAF (описан в проекте):
http://bal10.chat.ru

Прошу критику.

Возникли проблемы с сервером nightmail.
Я выложил BAL на 
http://bal10.chat.ru, http://bal10.land.ru, http://bal10.by.ru
(задублировал на случай эксцессов и с этими серверами)

Модератор: перемещено из Общие вопросы по базам данных.

Товарищи, продолжаем обсуждение.
Вопросы, замечания, предложения есть?

О применении языка:
запросом в базе данных получить сразу дерево, а не декартово произведение
http://bal10.chat.ru/site/bal/ru/tree_ru.htm
и отправить его сразу в браузер
http://html60.chat.ru/site/html60/ru/anytag_ru.htm
- это вместо того, чтобы писать генерацию html-страницы на php или perl.
Определить свойство "kind" в css-файле - это проще, чем писать полноценный XSL.

Т.е. в первую очередь речь идет о сопоставлении старого метода "3 языка" (html+php[perl]+sql) и
нового метода "2 языка" (html+bal)"

Кроме проекта HTML 6.0 язык предназначен для использования в проекте Computer 2.0
http://computer20.chat.ru

Если честно, то жуть большая. Не буду говорить о BAF процессоре, это вообще жуть. Ты вероятно не подумал, что поиск по списку дырок это самый медленный способ выделения памяти (почитай на досуге продвинутые malloc или лучше менеджеры памяти C# или Java), а когда оно зашито в железо, то вообще труба (больше логики, больше транзисторов, больше потребление энергии, больше греется, жёсткая привязка программ к не эффективной модели выделения свободной памяти). Проблем по дизайну ещё масса 

О BAF как о формате файла базы данных. Ты вообще слышал о InnoDB (построковые блокировки, транзакции и т.д.)? А о StringBTree (эффективное хранение инфы с индексами, набери в гугле). А о том, что boolean поля в памяти проца хранятся полным словом процессора (32 битным), так что описание как хранятся logic и прочие типы оборачивается в ловлю блох? Про права доступа ты там зря, не для "чистой базы" это дело, при чём вещь это сложна, с ролями и привилегиями, а не запись/чтение/выполнение.

BAC (кстати не скачивается) так вообще апогей "я ничего о том что в мире делается не знаю!"     Ну скажи мне, ну зачем придумывать ещё одну универсальную кодировку для всех языков если уже есть признаный всем миром Unicode? И как ты решил положить всё в 1-байтовые символы? Или инновация в том, что сегменты текста размечаются мета-инфой (спец. символами), где указан язык?  А не подумал ли ты, что если пара байтов такой мета инфы умрёт, то текст восстановить будет очень сложно? А работать с таким текстом (сравнение, upper/lower case и прочие операции) вообще в не человеческий геморрой превращаются, т.к. простейшими range таблицами тут не обойтись. Вообще BAC это то, что больше всего убило   

Про "дыры" и вообще выделение памяти я уже писал в BAF процессоре. Движок базы вообще то поднимает большое (в пару Gb) количество данных в кеш, откуда и работает с ними. Это эффективно, т.к. множество тредов могут быстро блокировать друг друга, хотя тут часто применяется собственный мини-кеш для каждого треда. Так вот инфа из кеша постоянно сбрасывается на диск, именно поэтому никто не может точно сказать где и как будут расположены записи в файле, они действительно постоянно переписываются. Отсюда и "дырок" как таковых нет, переписываются целые сектора, заодно избавляясь от фрагментации. Вывод: смотри шире, список дыр это не эффективно и главное не модно 

Не понял как выполняется поиск по такой базе данных. Не, конечно зная смещение очень просто найти запись, да только не будем же мы жёстко прописывать смещения для каждой записи ведь и вшивать это в прогу   Также нужно элементарно найти что нибудь (строку) без перебора, а индексов то нет. Или есть какая мощная концепция, по которой инфу нам искать никогда  не нужно (всё моё мировоззрение поменяешь    ).

Извиняюсь, на всё остальное у меня просто не хватило сил и времени   
Сложилось впечатление, что ты начинающий программист-схемотехник, который спит и видит как бы сэкономить пару байт, со временем это проходит, когда врубаешься что же такое быстрое выполнение проги. Помни, что простой PC с 2Гб памяти и 250Гб на жёстком диске это обычный средний комп. Также помни, что многое (в твоём случае всё, что я успел прочитать) уже придумано другими с описаниями и замерами производительности, именно от этих изысканий нужно строить и оценивать своё, а не слепо изобретать велосипед.

P.S. HTML6.0 слишком крутой номер, любые теги и сейчас понимаются браузером если есть соответствующие CSS стили (не знаю на каком браузере ты пробовал). Остальное дело шаблонизатора и разметки не касается. Напомню что HTML это разметка на клиенте, а клиенту пофигу откуда инфа, сам он её дёргать не будет (ну только если скрипт возьмёт, но это и не разметка).

>поиск по списку дырок это самый медленный способ выделения памяти
>когда оно зашито в железо

реализуется программно - это не к процессорной архитектуре

По последующему тексту: формулируйте так: "А хуже В потому что".
А то невозможно понять с какими аргументами вы выступаете.

>BAC (кстати не скачивается)

http://bac10.chat.ru

>зачем придумывать ещё одну универсальную кодировку для всех языков если уже есть признаный всем миром Unicode

Идея была:
1. вставить индексы в текстовый файл
2. привести разницу слов в одном знако-месте "заглавныя буква - строчная буква"
   в разницу "лишний байт"
3. вставить спец-символы в текстовый файл для изменения размера и цвета букв

Остальное - число исследовательское прощупывание.

Остальные вопросы про BAC вы вероятно откорректируете после прочтения документации.

>Про "дыры" и вообще выделение памяти я уже писал в BAF процессоре. Движок базы вообще то поднимает большое (в пару Gb) количество данных в кеш, откуда и работает с ними. Это эффективно, т.к. множество тредов могут быстро блокировать друг друга, хотя тут часто применяется собственный мини-кеш для каждого треда. Так вот инфа из кеша постоянно сбрасывается на диск, именно поэтому никто не может точно сказать где и как будут расположены записи в файле, они действительно постоянно переписываются. Отсюда и "дырок" как таковых нет, переписываются целые сектора, заодно избавляясь от фрагментации. Вывод: смотри шире, список дыр это не эффективно и главное не модно 

Несколько сумбурно.
Объясни еще раз внятно и последовательно.

>не будем же мы жёстко прописывать смещения для каждой записи ведь и вшивать это в прогу

Не в прогу, а в поле другой записи.

>найти что нибудь (строку) без перебора, а индексов то нет

вставляя запись сразу записываете ее адрес в соотвествующих других записях


Стержень проекта - построение СУПЕР-КОМПЬЮТЕРА руками чайника.
Хранение и передачу информации между процессорами предлагается выполнять так,
чтобы она не могла быть использована не по назначению.
И контролировать это максимально жестко - аппаратно.
Для этого и контроль типов, и контроль класса сущности (с помощью механизма сегментов).
[С целью оптимизации использована не реляционная модель данных, а деревянная]
Таким образом речь идет о хранении и передаче ПРОИЗВОЛЬНОЙ СЕМАНТИЧЕСКОЙ информации.

Сделано это таким образом, чтобы код процесса-отправителя и процесса-получателя не зависел от того,
находятся они в одном и том же процессоре, или в разных
(процессы перемещаемы по процессорам ОС-ой).

Передача между процессорами служебной информации
(номер процесса, номер сегмента, код машинной команды, смещение, микросмещение)
расчитана в первую очередь на ситуацию, когда получение небольшой порции данных вызывает
процедуру по ее обработке
[т.о. единичное данное может привести к большим по масштабу и
длительным по времени изменениям в работе процесса-получателя].
Для иных ситуаций предусмотрена возможность передачи многих данных
с единственным на всех набором служебной информации.


Эта схема процессора рассмотрена на примере построения видео-ОС для видео-процессора
(отличие ВП от ЦП состоит только в том, что его схемотехника выдает еще и видео-сигнал
на основании данных, содержащихся в его памяти).
Изложена довольно примитивная видео-ОС, но ничто не мешает дополнить ее схему данных
сущностями, информирующими о движении объектов, или изощренными спец-эффектами.
В предложенной концепции ЦП занимается только СОДЕРЖАТЕЛЬНОЙ частью программируемой задачи.

Актуальность примера исходит из того, что
на этапе изучения прочитать описание схемы базы данных легче,
чем изучить библиотеку программирования,
а при выполнении работ заполнять базу проще
(и это не зависит от инструмента, будь то язык программирования или частное ПО),
чем вызывать традиционные процедуры по визуализации
(вспомните, что последнее до сих пор массы делать не могут).

>любые теги и сейчас понимаются браузером если есть соответствующие CSS стили

Что является аналогом свойства "kind"?

Судя по описанию проца он этим занимался, вероятно "не правильно" прочёл? 


Я редко говорю открыто, что одно хуже другого. Буду предлагать альтернативы, а ты решай что "лучше"   


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


В смысле? Какой байт? И почему байт? Разве не проще работать с "символами", не важно сколько байт такой символ занимает? 
Помним, что помимо кодирования текста нужно с ним ещё и работать, т.е. искать по нему, трансформировать и т.д. Это надо делать быстро и если можно, без перебора всех символов из-за "переключений языка". Мы любим UTF-8, но в памяти работаем с UCS-16 именно по этой причине.


Мы ушли от этого наверное лет 10-15 тому назад, ибо все поняли что лажа. Разметка должна быть ясной, без контрольных символов. XML с этим идеально справляется.


Ты бы выложил свои причины/проблемы, обмозговали. Впрочем если это чисто лингвистическая проблема закодировать все алфавиты, то не надо 



Странно, что было не ясно? Современный комп обладает массой ресурсов, прога эффективно использующая всю память серьёзно отличается от проги потребляющей минимум ресурсов. Нормальный движок БД подгружает целые сектора файла/файлов БД и сбрасывает на диск тоже целые сектора. Поясню, сектор это не дисковый сектор, это большой участок файла фиксированного размера    При записи такого сектора не отслеживаются "ссылки" на записи (физически не реально без каскадных обновлений других секторов), именно поэтому ни в одной серьёзной БД ссылки не реализуются смещением/адресом по файлу. 

Штудировать: Fundamentals of Database Systems (Addison-Wesley| Ramez Elmasri & Shamkant B. Navathe), ISBN: 0-201-54263-3
От корки до корки, свои глупости сразу станут ясны, заодно почерпнёшь необходимые знания.


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



Это громкое заявление  


Я не заметил этих деталей. Укажи конкретней в своей доке, где описываются эти механизмы. Миграция процессов сейчас реализуется либо полным переносом копии объекта, что эффективно для долговременного переезда; либо через прокси объекты. Покопай на эту тему Java RMI, мощная и гибкая вещь.


Это ты сейчас не подумав сказал. Графический процессор решает совсем другой круг задачь, потому и оптимизирован именно под них. Например наложить фильтр на растровую картинку можно обычным процем по пиксельно, или графический сделает это же в несколько потоков. Наличие блоков для быстрого умножения, взять ARGB пиксель (а не просто слово), сложить два ARGB пикселя (прозрачное наложение) и многое другое реализовано прямо в железе. А RAMDAC прикрутить можно к любому процу и генерить видео сигнал 



Ты отстал от жизни... современная графическая карта уже понимает 3D сцену вертексами, врубается что есть камера и т.д.; позволяя тебе совершать "высоко-уровневые операции" как поворот камеры или изменение группы вершин. При чём программисту это доступно ещё и в "поточном" стиле в шейдерах, через которые ты можешь просто натянуть текстуру, расчитать свет, применить фильтр (например сглаживание) ко всей сцене и т.д.


Ёлки, подпишусь на эту тему, а то забываю и возвращаюсь по ссылкам из юмора