guest_20040621> Троллинг?

Нет. Четкая последовательная позиция. Полистайте форум.
А почему шифруемся?

Программист-ЛюбительEmeryЛучший критерий истины - практика :) .
"Нет ничего практичней хорошей теории"
Как говорил декан одного физфака: «Дайте мне любую теорию, а эксперимент мы подгоним» :-) .

SERG1257EmeryЛучший критерий истины - практика :) . Ссылочной целостности нет, уникальности на уровне БД нет, запросы сложные донельзя см пост Last1Cmen
Да, все значения проиндексированы, но простая выборка одной строки размазана по всей таблице V (значения)
Ну, вообще-то, главная проблема в отсутствии универсального клиента, а не в организации доступа к данным. И кто нам мешает использовать для универсального клиента промышленные базы данных? Например, Вам не нужна история модификаций данных, а мне «ссылочная целостность» и «уникальность на уровне БД». За сложность запросов я также не переживаю, если я все контролирую, то и запросы оптимизирую под себя. Я ведь не средство разработки предлагаю, а конечное решение, конфигурацию, в терминах 1С. Причем, в этом случае нет необходимости в пользовательском творчестве по построению изощренных запросов. А все прогнозируемые, фиксированные запросы всегда можно свести к простому доступу по нужному индексу или группе индексов.

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

БредятинаEmeryЯ вот проектирую для себя структуру данных для учета на предприятии и возникла интересная идея по универсальному представлению данных в некой базе данных.
И Вам нужно посмотреть модель TransRelational Стива Тарена, чтобы быть, все-таки, в курсе того, что делается в этой области - в области хранения, а не представления, как Вы выразились, данных в БД [U.S. Patent and Trademark Office: Value-Instance-Connectivity Computer-Implemented Database. U.S. Patent № 6009432, 28.12.1999; для простого понимания см. Приложение 1 у Дейта]. Может тоже патент получите:)
Спасибо за информацию! Только на патент данная идея не тянет, т.к. подпадает под довольно широкое определение EAV. Только у меня более конкретно, а у них более абстрактно, хотя для посторонних их идея малопонятная. Тем более, какие патенты в Эпоху Перемен? :-) .

Однако куда более актуальным является вопрос «идеального» клиента. Армия программистов со всего мира, пишет все, что угодно, кроме очень востребованного универсального клиента для различных серверов БД, так чтобы можно было контролировать процесс обмена данным между сервером и клиентом.

БредятинаEmeryВедь все поля предлагаемых таблиц будут проиндексированы.
А в TR индексы вообще не нужны:)
Выходит, что не нужны, по крайней мере, для тех задач, которые я решаю.

БредятинаEmeryА любой SQL держится, по сути, на индексах.
Индексы не имеют никакого отношения ни к SQL, ни к РМД.
Очень даже имеют, только движок БД скрывает это от пользователя, а если очень нужно, то сам индексирует, никого не спрашивая.

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

БредятинаEmeryНет проблем, три поля по одному байту всегда будут пустыми и общих записей будет меньше. Так что не большая цена :-) .
Еще какая проблема:) Во-первых, цена приличная, а, во-вторых, какие еще байты у пустых полей? Это вообще прошлый век в хранении данных:)
Имеется в виду ширина полей в байтах. Значения могут быть либо пустыми (символ «пробел»), либо символом нуля («0»), так как поля даты модификации строковые. Впрочем, символ с кодом NULL тоже допускается.

Три байта на миллион записей, дадут 3 мегабайта пустых данных. Это что проблема в эпоху терабайтных винтов?

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

БредятинаEmeryОднако куда более актуальным является вопрос «идеального» клиента. Армия программистов со всего мира, пишет все, что угодно, кроме очень востребованного универсального клиента для различных серверов БД, так чтобы можно было контролировать процесс обмена данным между сервером и клиентом.
Под "идеальным клиентом" можно понимать только полностью управляемый пользователем интерфейс. А для этого нужна семантическая модель. Способ хранения не имеет к этому никакого отношения:)
Так я и пишу: «чтобы можно было контролировать процесс обмена данными между сервером и клиентом». И речь мы сейчас ведем о клиенте, а не о сервере. С серверами БД проблем нет, они уже давно решены. А вот проблемы с «полностью управляемым пользователем интерфейсом» остались, хоть с «семантической моделью», хоть без нее :) .

БредятинаEmeryОчень даже имеют, только движок БД скрывает это от пользователя, а если очень нужно, то сам индексирует, никого не спрашивая.
Индексы не имеют никакого отношения ни к SQL, ни к РМД. Это же факт:) А вы говорите о неудачных реализациях, которые что-то скрывают:) Вот когда тоступ к индексу обеспечивается в терминах модели данных, тогда, конечно, имеют отношение.
Тогда объясните мне, как делается запрос на выборку одного уникального элемента из базы, содержащей сто миллионов записей? При условии, что критерий поиска не индексирован. Обычный scan?

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

guest_20040621> А почему шифруемся?

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

guest_20040621> Мои собственные конфигурации в 1С77 и проще и эффективней стандартных

В данном случае опыт играет отрицательную роль. Попробуйте забыть про одинце - вы поразитесь, настолько много интересных решений вокруг.
Меня интересует универсальный клиент с конфигурируемым интерфейсом, виртуальным режимом для контрола списка / грида, типа как для SysListView32, поддержка групп, возможность привязки к дереву, типа SysTreeView32, перехват сообщений виртуального режима. Что можно взять из Вашего множества «интересных решений вокруг» для этих целей?

БредятинаEmeryИ речь мы сейчас ведем о клиенте, а не о сервере. С серверами БД проблем нет, они уже давно решены.
В этом и заключается самая большая проблема:) Ваша и Вашего подхода. Непонимание огромных проблем серверов БД, ориентированных на не эффективные модели данных:)
Вы знаете мои проблемы лучше меня :) ?
Мои модели реально работают и фактически кормят меня. Я знаю, как еще улучшить их работу. Но мне нужен универсальный (идеальный) клиент. Я могу и пытаюсь писать его сам. Но это отнимает много времени. Начнем с того, что нет 100%-но подходящего грида / списка. Затем нет хорошего конфигуратора интерфейса, «отвязанного» от источника данных. Меня не устроит любой грид. Лучший, из бесплатных с исходниками, что я знаю, это грид Криса Маудера (Chris Maunder). Затем идет грид Алькса (ALX или Алексей Долгачев), затем различные расширения CListCtrl (SysListView32), вроде GfxList. Грид Алькса не поддерживает виртуального режима и групп. Грид Криса Маудера поддерживает виртуальный режим, но не поддерживает групп. SysListView32 очень хорош, но имеет скрытые параметры (т.е. намеренные ограничения для пользователя), Кроме того, для SysListView32 нужно самому писать инлайн редактирование. И так далее, подходящий грид найти очень сложно. А то, что нравится одним, может не понравится другим. Пока я юзаю SysListView32, особенно мне нравится этот контрол из Win7, но он не работает под ХРюшу. Несмотря на то, что примеров реализации инлайн редактирования существует много, реализованы они неудовлетворительно для меня. Как говорят, если хочешь, чтобы работа была сделана хорошо, нужно делать ее самому. Вот и занимаюсь списком SysListView32, вместо того, чтобы писать бизнес приложения :) .

Tolkaзачем для определения "историчности" записи заводить 3 отдельных поля? Кто-то когда-то будет задаваться вопросом, покажи записи, которые менялись по вторникам? Достаточно одного простого date поля
Чтобы ответить на Ваш вопрос, достаточно вести логгирование (журналироваие) изменений базы данных. История нужна, чтобы отслеживать, скажем, факт того, что Иванова, после замужества, стала Петровой, а кто-то может быть вообще пол сменил :) .
У сотрудника одновременно может быть несколько назначений, табельных номеров, графиков работы и т.д. Один, из которых, считается основным (для вывода информации в отчетах по сотрудникам). Те, кто на подмене, в разные периоды времени должны отображаться в разных подразделениях, и т.д. и т.п. Очень полезно такие реквизиты делать периодическими, что удобно для отслеживания, скажем, нескольких приемов увольнений в данную контору. Я не знаю случая из своей практики, чтобы нужна была история модификаций полей данных с точностью меньшей, чем сутки. Может быть Вы, к примеру, на почасовой оплате, когда Ваша ставка с 8:00 до 10:00 утра была одна, с 10:00 до 12:00 другая, а ближе к вечеру третья. И нужно составить отчет по сотрудникам, упорядоченный по размерам их ставок на время 12:30. Если нужна такая точность, то придется, конечно, вводить кроме даты еще и время модификации поля данных. Только сомневаюсь, что такая точность будет реально востребована. Даже когда человек работает посменно, и его смена переходит с одного дня на другой и в этот день ему повысили зарплату, то вряд ли потребуется точность фиксации повышения оклада с точностью до полусмены. Так что любая база данных всегда не абсолютна и очень часто компромиссна между желанием учесть больше информации и возможностью ее обработать и хранить. Я обычно ориентируюсь на реальную обстановку с небольшим запасом.

Что касается трех однобайтовых полей для даты модификации. Это сделано для удобства составления запросов. С атомарной информацией легче работать и меньше делать различных преобразований.

TolkaА что если нужна и история и быстродействие?

В EAV мы получаем развёртку сущностей по полям Nсущ*Nполей. А у вас, насколько я понял, получается Nсущ*Nполей*Nист...

берём среднюю таблицу с данными на несколько миллионов. Сущность имеет 20 атрибутов и 10 исторических записей. Получаем 10^6*20*10 = 2*10^8 = 200 млн записей...

как будет работать?

теперь принимаем, что у одной сущности один из строковых атрибутов, скажем 10 символов, а у другой - 100, а у третьей - 500. И все они славно так проиндексированы одним индексом. Какой индекс будет работать быстрее? По 200 млн записей и средней длине 250 символов или по 3 миллионам и средней длине 10 символов?
Неправильно так перемножать. Возьмем для примера «плоскую» таблицу сотрудников. Ввод времени модификации делает ее формально «трехмерной». Только «третье» измерение будет очень редким. Скажем, та же Иванова стала после замужества Петровой, а затем, после второго замужества, Сидоровой. Это дает только две дополнительные записи к «плоской» таблице сотрудников. Далее, пусть Вася Пупкин три раза принимался на нашу работу и два раза увольнялся. Это дает дополнительно еще 3 записи. И так далее. Т.е. для редкой истории (не зря фирма «1С» называет справочники «условно-постоянной» информацией) «третье измерение» не перемножается, а суммируется. Там же, где фиксируются операции и на их основе документы, может потребоваться учет до минуты. Но это будет учет не в «третьем измерении», а во «втором». Документы не должны содержать периодических реквизитов. После их проведения, все ссылки замещаются их значениями на время проведения и данные документов фактически замораживаются. Другое дело, если Вы делаете перепроведение. Тогда данные могут «разморозится». Т.е. «трехмерными» могут быть только первичные таблицы (справочники или таблицы определений), а документы (вторичные таблицы – таблицы операций или таблицы отношений) всегда должны быть только «плоскими».