iscrafmВы путаете понятия. Общественное мнение здесь не причем. Самоубийц просто, обычно, пытаются отговорить не делать откровенную глупость.
Если аргументов не хватает, прибегают к сильным словечкам. Зачем использовать запрещенные приемы?

iscrafmEmeryБез УК очень тяжело полноценно реализовать предлагаемую модель хранения данных. Поэтому приходится говорить и об универсальном клиенте.
следующим шагом будет разговор о специализированном компьютере, необходимом для реализации какой-то модели данных , представляющей собой какую-то, странного вида таблицу в БД, для работы с которой требуется какой-то универсальный клиент, на роль которого не подходит не один из тысяч существующих клиентов. Жду с нетерпением.
EAV придумали до меня. Я всего лишь предлагаю его конкретную реализацию, не более. «Тысячи существующих клиентов» завязаны на свои движки БД. Я предлагаю «развязать» хотя бы один из них. Кстати, в MFC класс CListCtrl использует именно такую идеологию. Нужно всего лишь построить приложение на его основе, что я и делаю. Странно только, что никто другой этого еще не сделал.

БредятинаНо Вы, выходит, продолжаете не понимать, что к модели данных (РМД) индексы не имеют никакого отношения. Наверное поэтому Вы взяли из моего сообщения только нужную Вам фразу:)
Хорошо, объясните своими словами, как можно работать с БД без индексов, с той же и большей производительностью.

БредятинаА там же было и это
"Что касается РСУБД, о которых Вы, видимо, рассказываете, то в них индексы хоть и скрыты, но они ведь, действительно не имеют отношения ни к РМД, ни к SQL. Это просто еще одна форма денормализации данных, не укладывающаяся в реляционную теорию (поэтому и скрыты:)), и приводящая, как обычно, к повышению производительности за счет избыточности данных."
А в других сообщениях подробнее о доступе к индексу в терминах модели данных:)
Сама по себе избыточность данных не дает прироста производительности, хотя и способствует ей. В моей терминологии это предварительная обработка данных. Сделав часть работы заранее, Вам не придется делать ее в критически важный (по затратам времени) момент. Но я откровенно говоря не понимаю Вашего игнорирования индексов, этого краеугольного камня БД. Какой механизм Вы предлагаете взамен? Так чтобы это можно было понять и прочувствовать. Насчет Ваших рассуждений об «еще одной форме денормализации данных, не укладывающихся в реляционную теорию» я вообще ничего не могу сказать, так как совершенно не понимаю смысла этой фразы. Можете объяснить «на пальцах»?

БредятинаО "расширяемых средствах разработки", похоже, замяли:) Что и следовало ожидать:)
Я процитировал только Ваши слова, обсуждение этого вопроса я не начинал, потому и развивать его не собираюсь, так как это уведет нас далеко в сторону.

Alibek B.Предлагаю пойти дальше.
Первая таблица — метаинформация о полях (названия, ключи, типы данных и длина).
Вторая таблица — содержимое, но сами значения в ней не храняться.
Третья таблица состоит из трех полей, ключа на вторую таблицу, порядкового номера и однобайтового поля.
Для получения значения поля нужно извлечь все подчиненные записи из третьей таблицы и объединить их.
Т.е. можно забыть о нерациональном использовании пространства, все данные будут занимать именно столько байт, сколько они занимают.
Как идея?
Если бы еще понять, что Вы имеет в виду :) ? Нарисуйте примеры этих таблиц, может тогда будет яснее.

БредятинаEmery Без УК очень тяжело полноценно реализовать предлагаемую модель хранения данных. Поэтому приходится говорить и об универсальном клиенте.
Что-то Вы запутываете простой вопрос:) Реализуйте для начала предлагаемую модель хранения данных, абсолютно полноценно, на СПЕЦИАЛИЗИРОВАННОМ клиенте. Модель хранения будет реализована абсолютно полноценно:) Что здесь очень тяжелого?
Если бы существовал клиент, для которого можно реализовать данную схему, хоть специализированный, хоть универсальный, то данной проблемы не существовало бы. В любом случае, нужно либо писать собственно клиента (реально он будет далек от идеального универсального клиента), либо использовать любой существующий, но хакерскими методами делать в нем перехват сообщений виртуального режима, если он там поддерживается. Можно еще взять исходники проекта «2С», написанного на MFC, и поработать с ними. В любом случае, каждый вариант трудоемкий. Я пока остановился на собственном клиенте. Но дело движется медленно. Текущее состояние проекта можно посмотреть на моем сайте .

Alibek B.Зачем?
Все базы данных на нижнем, "железном" уровне и так "развязаны" до конца.
Всех этих столбцов, строк, представлений, индексов не существуют, существуют только плоское пространство байт. А уровнем ниже — "единицы" и "нули", определяемые намагниченными областями.
Разработчики СУБД вложили много времени и усилий, чтобы работа с данными осуществлялась через абстракции.
Лепить поверх этой абстракции свою самодельную "антиабстракцию" глупо. Если уж так хочется универсальности, разрабатывай свой бинарный формат данных.
Я подозреваю разработчиков современных СУБД в недобросовестности, в избыточной коммерционализации своих БД, в наведении «тень на плетень». А вместо «своего бинарного формата данных» я лучше сделаю своего клиента на базе SysListView32 :) .

iscrafmАргументы уже все приведены.
Но почему-то неубедительные :) .

iscrafmмда... Вам название класса понравилось в MFC? И что во там предлагаете "развязать"? Рановато. И какой хотя-бы один?
Не «название класса», а сам контрол. Вот, допустим, Вы хотите запустить в своем приложении собственный экземпляр comctl32.dll (где «живет» SysListView32). Вы можете даже явно вызвать свою версию этой библиотеки, отличную от системной, использовав LoadLibrary / GetProcAddress. Но все равно будет использоваться библиотека, прописанная в реестре и загруженная системой. Для того, чтобы заставить работать именно Вашу длл-ку, Вам нужно в шестнадцатиричном редакторе поменять имена типа SysListView32 / SysHeader32 и связанные с ними на свои имена. Так SysListView32 у меня стал SysListCtrl32 и т.д. Жаль только, что comctl32.dll из Win7 не работает под XP или Win2003. Разве только перекомпилировать эту длл :) ? Для мегабайтой comctl32.dll версии 6.0 у меня это получилось, и даже некоторые функции удалось выполнить, но за устойчивую работу всей библиотеки не уверен.

iscrafmp.s. что такое EAV вы узнали только в этом форуме, на первой странице. Страшно даже предположить, сколько еще неизвестных слов, кроме CListCtrl.
Узнать, то я узнал, только что узнал я нового? Только то, что подобная технология кем-то из буржуев изобретена до меня. Но я и так не претендовал на авторство, ибо идея эта «витает в воздухе». И что толку от бесполезных «умных» словечек, кроме как оказать впечатление на непосвященного?

БредятинаРечь тогда будет простой и абсолютно понятной, что очень важно, особенно при обсуждении технических вопросов. А вот Вы к двум бесполезным терминам добавили еще один "первичная таблица данных":) А все из-за того, что мы до сих пор не знаем о какой модели данных в слое, который Вы, от безысходности, надстраиваете над реляционной моделью данных (так как РМД не позволяет решать Ваши задачи), идет речь:)
Какой Вы, однако, категоричный! Не нравится Вам предлагаемая терминология, ну и не используйте ее. Мне она удобна и полезна. Я пока еще ничего не «надстраиваю», а просто решаю проблему с программированием своего клиента. Будет ли он работать по предлагаемой модели хранения данных или по другой, не суть важно. Достаточно будет если я перенесу свои работающие конфигурации из 1С77 на своего клиента, естественно с усовершенствованиями. А нравится Вам эта идея или нет, понятна или нет, это уже другой вопрос. Про свои конфигурации я много писал здесь на форуме. Народ в основном воспринимает в штыки, что меня очень удивляет. Вам то какая разница? Конфигурации работают, все проблемы решают – почему это Вас раздражает? Вот решил подумать об их усовершенствованиях и опять критика. Давно думаю, что надо молча работать :) . Тогда ненужных проблем будет меньше :) . Я ведь ничего не спрашиваю, просто делюсь информацией. Полезных идей все равно почти не слышно.

БредятинаАналогия совершенно не уместна:) Вы вынуждены были изменить свое решение, и не записывать в документ, а подразумевать, видимо, в своем сознании:)
Теперь, что касается операции возврата отгруженной продукции.
Вы отгрузили пиво 25.12.2010. Характеристики пива в "документ" не записали, но "подразумеваете":). То есть, если их посмотреть, так сказать, из этого документа, то мы должны увидеть характеристики на 25.12.2010. Возврат осуществлен 30.12.2010. К этому времени некоторые характеристики пива в БД изменились. Вы говорите, что при просмотре характеристик из "документа на возврат" мы должны видеть характеристики на дату отгрузки, а не на дату возврата. Это же не имеет никакого отношения к процедуре "прописывания характеристик в документ". Вы же уже согласились, что это не нужно делать? И какая же здесь "аналогия"?:)
Пять дней для консервированного пива погоды не делают. Но попробуйте вернуть то же самое пиво после его срока хранения. Торговля не имеет права продавать простроченные продукты. Хотя кто нынче блюдет законодательство? В общем, свою мысль я высказал, но ничего доказывать не собираюсь. Вы можете вести учет по своей учетной политике, а я по своей и никаких проблем.

БредятинаEmeryТак что 1С тут ни причем.
Очень даже при чем. Ведь можно просто откорректировать операцию (одну из десяти в документе, предположим), и получить точно такой же результат:). Точно так же можно сделать и в закрытом периоде. Просто в этом случае корректировка возникнет в текущем открытом периоде. Термин "проведение" возник от термина "проводка бухгалтерская". Но бухгалтерские проводки ведь автоматически делаются, о них вообще можно не беспокоиться:)
Понятно, что Вы исходите из своего опыта работы, который отличается от моего. Отсюда и недоразумения. Для меня «проведение» означает «фиксацию данных», с одной стороны и дублирование данных, упорядоченных по другим индексам и / или в других таблицах (с целью ускорения доступа к данным) с другой. Понятно, что под это определение подпадают бухгалтерские проводки. Но для меня они отнюдь не первичны. Для меня первичны натуральные операция, а бухгалтерские операции вторичны. Поэтому и бухгалтерские проводки я программирую сам, а не использую стандартную «Бухгалтерию для Украины», скажем. Также и учет ресурсов и начислений (з/п, в основном) я тоже делаю по своей модели учета, отличной от прикладной модели учета братьев Нуралиевых.
Можете сколько угодно доказывать, что я не прав, но моя модель работает и полностью меня удовлетворяет, если не считать ограничений самого ядра 1С77.

БредятинаТо, что Вы описали используется на стороне РСУБД. Это уже очевидно. Я спрашиваю о модели, которая будет описывать предметную область для пользователя, и, соответсвенно, использоваться в "универсальном клиенте"
Если хотите, модель отображения данных в клиенте будет похожа на работу моих конфигураций (которые 1С-несовместимы) в «семерке». Моя модель мне очень нравится, если не считать ограничений ядра 1С77. Основная суть ее – это первичность натурального учета и вторичность бухгалтерского учета (который правильней назвать «бухгалтерским контролем» :) ) . Детали, я когда-нибудь опубликую полностью. Новых локальных идей там реализовано много. А как данные будут храниться в БД, это уже другой вопрос. Буду пробовать разные варианты, не считая уже реализованного.

БредятинаЯ не про реализацию же спрашиваю:) Еще раз:
Какой "элемент" в Вашей архитектуре обеспечивает независимость от модели данных сервера БД? Как будет работать в случае IMS, например.
Я же Вам говорил, все, что мне нужно, это возможность самому обрабатывать уведомления виртуального режима списка SysListView32 (CListCtrl в MFC). Никакого другого «элемента» мне не нужно. Это все будет реализовано в той программе, что я пишу сейчас.

Emery «Делать», в смысле «программировать», «разве это не очевидно» :) ?
Еще как очевидно:) Из этого следует, что программист будет программировать запросы. Я и говорю: надеюсь, что это опечатка:) Очевидно же, что программист не должен программировать никакие запросы, они ведь будут появляться произвольным образом в процессе эксплуатации приложения. Или Вы что-то другое имели в виду? Например, процесс "настройки" на новый "сервер БД"?[/quot]
Да нет, пожалуй, то, что Вам не очень нравиться :) . В ссылке выше я привел пример работы с данными, по интересуемой меня методологии. Там продемонстрирован доступ в виртуальном режиме из списков к трем dbf-файлам, с которыми я работаю непосредственно. Пример пока простой, но с перспективой на многомегабайтные базы. Более того, я сейчас собираюсь реализовать собственный вариант создания и поддержки компаундных индексных cdx-файлов. Кое-что по этому поводу есть на моем, процитированном выше, сайте. Только можете не тратить свое время на критику этой идеи. Я уже много ее услышал и вряд ли Вы добавите что-то принципиально новое. Вот ALX (Алексей Долгачев) занимался подобными разработками, но я собираюсь идти дальше.

БредятинаEmery Хорошо, объясните своими словами, как можно работать с БД без индексов, с той же и большей производительностью.
Так Вы согласны, что в РМД нет никаких индексов?:) Я Вам об этом говорю, а не о том может ли РСУБД работать без индексов. Кроме того, я Вам уже объяснил, что может. Дейт считает, что TR (в которой, по сути, нет индексов) - это и есть схема хранения для "настоящей РСУБД". Вы хотите это оспорить?:)
Говорить, то Вы говорили, но объяснить своими словами, как можно работать без индексов не хотите. Допустим Ваш Дейт прав, но почему бы Вам не объяснить в двух словах суть его идеи, за счет собственно чего достигается эффективность доступа к данным в БД, организованной по его методалогии?

БредятинаКонечно. См выше. И где Вы увидели индексы в РМД. Там есть "отношения", "ограничения целостности (ключи", "операции манипулирования отношениями". Где там "индексы" Вы увидели:)?
Но за счет чего достигается скорость доступа к данным?

pil0tя разрабатывал несколько учетных систем, первая была как раз на EAV
в принципе, этот тип имеет право на жизнь, если мы работаем с небольшими объемами данных и нам не нужны некоторые возможности.
кроме уже обозначенных проблем с уникальными индексами и ссылочной целостностью возникает ещё вопросы с производительностью:
в случае "обычных" таблиц большинство современных субд позволяют разбить по разным дискам, применить партиционирование и др.
Если Вы сами контролируете создание таблиц, то можете хранить их на разных дисках тоже. Пока у меня нет нужды работать с промышленными данными. А для предприятия среднего уровня продуманная структура данных, в принципе решает все перечисленные Вами проблемы.

pil0tEAV может быть полезной штукой для хранения изменений во времени, некоторых OLAP, но не для OLTP операций

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

В случае одной универсальной таблицы, нам нужно блокировать по строкам (хранить в памяти все идентификаторы заблокированных строк) либо блокировать всю таблицу (а следовательно и всю систему) целиком.
Я не веду речь про «одну универсальную таблицу». Таблиц столько же сколько и было раньше, даже в два раз больше, так как нужно еще описывать их метаданные. Только вот структура у всех них будет единообразной, за счет собственно чего и будет сделана попытка усовершенствования доступа к данным.

pil0tДля хранения исторических сведений существуют разные варианты реализации можно погуглить или вот например ( http://habrahabr.ru/blogs/sql/101544/)

Спасибо за информацию! Посмотрю уже после Нового Года!

Всех с Новым Годом!

Emerypil0tДля хранения исторических сведений существуют разные варианты реализации можно погуглить или вот например ( http://habrahabr.ru/blogs/sql/101544/ )
Спасибо за информацию! Посмотрю уже после Нового Года!
Интересные рассуждения, но не более. Для меня ничего полезного. Хранение истории модификации я продемонстрировал на примере второй таблицы в начале этого топика. Там есть поля: год модификации (достаточно одного символа от "0" до "9" или от "A" до "Z", что даст диапазон дат: 2000 – 2036 года, вполне достаточно для наших целей); месяц модификации (от "0" до "9" или от "A" до "C" – эквивалентные 1 – 12 месяцу) и день модификации (от "0" до "9" или от "A" до "V" – эквивалентные 1 – 31 дню). Изменения поля начинают действовать с даты модификации, до тех пор, пока не наступит следующая модификация, что зафиксируется определенной записью. Отсутствие даты модификации означает, что значение действует с «нулевого» времени, фактически с начала учетной даты в данной системе. Если диапазона в 36 лет будет недостаточно, то можно выбрать год двухбайтным (в 36-тиричной системе отчета, что даст диапазон дат в 1296 лет, точку отсчета можно выбрать произвольной, например 1500 год и т.д.). Данной информации вполне достаточно для хранения истории модификации данных первичных таблиц, т.е. таблиц определений (некоторых объектов, представимых своими записями в «плоской» таблице базы данных). Во вторичных таблицах или таблицах отношений (между объектами, определенных в первичных таблицах) модификаций полей данных быть не должно, поскольку они фиксируют операции, на определенную дату / время. Само же логгирование (журналирование) любых изменений в БД можно вести в специальном журнале.