Tolkaа про универсальный клиент вообще не въехал...о чём разговоры

это драйвер или гуи? Если гуи, то какое отношение он имеет к структуре базы?
«Универсальный клиент» это конфигурируемый интерфейс представления данных без привязки этих данных к источнику данных. Обмен данными между Сервером БД и Универсальным Клиентом должен программироваться «вручную» и в принципе не должен зависеть от Сервера БД. Т.е. программист сам делает запросы к Серверу БД на основе уведомлений (желательно) виртуального режима представления данных Универсального Клиента. Где-то так :) .

guest_20040621Это не мешает вам задавать смешные вопросы, правда? Ситуация-то простая: вы, судя по вопросу и терминологии, ничего, кроме одинце и форточек в этой жизни не видели. И теперь хотите спроектировать что-то, что как бы уже не одинце, но как - не знаете. И вопрос вы задали потому, что не уверены, что выбрали правильный способ. Если ваша задача - интерфейс, вы на правильном пути, делайте, все получится. Если ваша задача - метамодель, забудьте про одинце и приготовьтесь много читать.
Ну почему не знаю? Знаю. Вопросов в теме топика я не задавал. Это была всего лишь информация для обсуждения (для будущей статьи). Чтобы опробовать предлагаемую модель (некую конкретизацию EAV), мне нужен универсальный клиент (УК), которого не существует. Поэтому вместо проектирования БД приходится заниматься разработкой УК. Но сначала нужно определиться с достойным гридом. Пока, несмотря на ограничения, мне нравиться SysListView32, особенно из Win7, поддерживающий группы и виртуальный режим до 100 миллионов записей (ограничение искусственное и легко устраняется). Давайте не будем вести споры, зачем нужно или не нужно 100 миллионов записей, об этом я говорил уже много раз. Будем исходить из аксиомы, что раз Мелкософт реализовал поддержку своего виртуального режима на таком уровне, значит это кому-то действительно нужно. Иначе, ограничился бы десятью тысячами записей, как предлагалось здесь на форуме. Чтобы разобраться со скрытыми возможностями SysListView32 приходится «глубоко копать», например, использовать очень недокументированные возможности :) .

В седьмой версии 1С есть несколько удачных идей, но какая бочка меда без ложки дёгтя :) ? Жаль, что 1С77 остановился в развитии. То, что мы критикуем его и призываем «забыть», я бы отнес скорее к версии 8.х, чем к 7.7. Но повторю, некоторые идеи семерки достойны реализации в альтернативных продуктах.

vadiminfoEmery «Универсальный клиент» это конфигурируемый интерфейс представления данных без привязки этих данных к источнику данных. Обмен данными между Сервером БД и Универсальным Клиентом должен программироваться «вручную» и в принципе не должен зависеть от Сервера БД. Т.е. программист сам делает запросы к Серверу БД на основе уведомлений (желательно) виртуального режима представления данных Универсального Клиента. Где-то так :) .
Такие идеи приходят большинству проггеров недавно пришедших в проблемную область баз данных. Т.е. это не оригинальная идея, ну и как показала практика (типа какой-то там критерий истины) они обречены: все это уже с 90 было много раз.
Ой, ли? «Недавно пришедшие проггеры» не проявляют никакой самостоятельности мышления. Ко мне в отдел устраивались на работу четыре выпускника программиста из разных ВУЗов. И хотя я никому не предъявлял никаких требований, кроме желания заниматься программированием, никто не захотел остаться (перешли на более «хлебные» места). И уж тем более никто не имел собственных идей в области программирования.

Если такие идеи приходят «большинству проггеров», то должны существовать их реализации, пусть неудачные, но они должны быть. Но нет никакого УК (универсального клиента) в природе. Есть конфигурируемый интерфейс в 1С77, MS Access, Microsoft Navision, Open Office org Base (OOo Base), SofMarket и т.д. и т.п., но везде конфигурируемый интерфейс привязан к собственной БД. И приходится очень изощрятся, чтобы хоть как-то повлиять на эту привязку в лучшую сторону.

vadiminfoНезависимость от сервера, оболчки, ядра, драйверы, конфигурируемые интерфесы. Все это попытки сдвинуть центр тяжести в замкнутой системе.
Нормальный путь: придумать свой тип МД, свою СУБД, или там если Рапид, то и свою среду разработки. Пытаться же использовать для своих типа идей средства предназначенные для других идей, это просто применение этих средств не по назначению. Многие возможности утрачиваются.
У меня другое мнение. В ДОСовские времена, в силу ограниченности ресурсов, базы данных были более дружественны к программисту и пользователю. Сейчас, БД завернули в такие монстрообразные оболочки, что многие эффективные ранее вещи воспринимаются ныне либо как табу, либо как повод для насмешек. А причина понятна, БД реально кормят своих разработчиков и они явно не заинтересованы в упрощении доступа и прояснения ситуации, связанных с ними. Пользователя и программиста отделяют стеной провайдеров и драйверов от непосредственного манипулирования источниками данных. А там где еще остался непосредственный доступ к БД, в Visual FoxPro, например, то его весьма эффективное ядро постоянно дискредитируют пропагандой и особенно, галимой реализаций его интерфейса, что в ДОСе, что в Виндозе. Короче говоря, идея БД ныне очень заполитизирована коммерческой идеологией.

vadiminfoВы знаете, есть такое предположение, что плохо спроектированной БД не помогут никакие програмные интерфейсы. Вы предлагаете чрезвычайно полохо проектировать БД (реляционная но реляционные запросы не канают - структура предметной области превращена в данные, а SQL предназначен для работы со структурой), ради независмости от БД. Концептуально слабым тут может оказаться, что БД важнее Вашего универсально клиента.
Логика понятна, раз «плохо спроектированной БД не помогут никакие програмные интерфейсы», значит это служит обоснованием отсутствия в природе универсального клиента :) .

Я предлагаю, прежде всего, разработать УК, к которому можно будет подключаться как с «плохо спроектированной БД», так и с «хорошо спроектированной». Я, например, еще не полностью реализовал все возможности технологии файл-серверного доступа к данным + терминальный сервер. Поэтому клиент-серверная технология у меня стоит на втором плане, к которой я перейду, после получения результатов на файл-сервере + терминал. Чтобы реально сравнить показатели работы своей БД. До сих пор у меня получалось работа с «легкими» серверами БД и мне не хочется без крайней необходимости переходить к «тяжелым» серверам.

iscrafmEmeryМои пользователи работают на моих конфигурациях и горя не знают, а десяток различных перепробованных стандартных решений для 1С вызвали категорическую реакцию бухгалтеров: «То, что могут делать эти конфигурации, нам не нужно, а то, что нужно, они не могут».
у вас какие-то специфические бухгалтеры. Вы даже не представляете, похоже , сколько бухгалтеров работают на типовых конфигурациях и горя не знают. Судить по нескольким знакомым - неправильно. Как говориться выборка нерелевантная.
Не бухгалтера «специфические», а стандартные конфигурации «1С» сырые, трудоемкие и плохо продуманные. Вообще-то тётеньки-бухгалтера народ не прихотливый и способны добросовестно работать даже на откровенном программном отстое. Только вот внедрять и сопровождать этот «отстой» очень мало желания. Проще написать свою конфигурацию, а еще лучше независимую от 1С программу и иметь дело с ней. А бухгалтерам, по большому счету, все равно, им главное, чтобы был нужный результат.

iscrafmнапоминает исповедь изобретателя велосипеда в 21 веке. Извините, сначала подумал о том, что тему можно рассматривать как серьезную, но после прочтения вот такого, всякое желание относится к этому серьезно отпадает.
Ну да, играю не по Вашим правилам :) . Если бы у меня была цель выглядеть серьезно, я бы больше молчал, с умным видом, кстати, это очень эффективная метода :) . Только, не интересно мне все это. Я хочу решения своих проблем по своим рецептам, а не по чужим. А мне говорят, ты не правильно хочешь, нужно хотеть по другому, тогда мы к тебе будем относиться серьезно :) . Но если человек хочет учиться на собственных синяках и шишках, предоставьте ему это право, это все же лучше, чем плыть безвольно по струе «общественного мнения». Лично я воспринимаю не отношение к своим идеям, типа, плохие или хорошие, а содержательную информацию.

БредятинаEmery Тогда объясните мне, как делается запрос на выборку одного уникального элемента из базы, содержащей сто миллионов записей? При условии, что критерий поиска не индексирован. Обычный scan?
Пользователь указывает значение и получает результат - один уникальный элемент. При этом он обращается, вероятно , к тому, что Вы называете индексом, но он не скрыт, конечно же.
Хорошее знание предмета, не правда ли :) ? Чтобы индекс существовал, скрытно или явно, неважно, нужно его сначала создать. Это делаете либо Вы, либо движок БД, с целью оптимизации. Если индекса не существует, то время доступа к произвольному элементу будет порядка O(N), где N – число записей. А если индекс уже создан, то время доступа будет порядка O(ln(N)). Сравните, если N = 10^6 = 1000000 записей, то в первом случае среднее время доступа будет равно const * 1000000, а во втором const * 6. Чувствуете разницу? Чтобы создать индексы даже по одному поля для миллиона записей нужно очень заметное время. Скажем, Visual FoxPro 9, создает индексы для строкового поля длиной 70 байт со скоростью 100-150 тысяч индексов в секунду. Для миллиона таких записей первый запрос на выборку заданного элемента составит порядка 10 секунд (если записи первоначально не были индексированны).
Второй подобный запрос будет уже выполнен практически мгновенно, ибо движок БД, уже создаст нужный индекс. Однако лучше подобные процессы контролировать явно. Проще всего создавать нужные индексы во время ввода данных, тогда на оптимальные запросы будет затрачено очень мало времени. А если Вы индексацию отдадите на откуп движка БД, то не удивляйтесь, когда такой монстр, как MS SQL Server будет иногда тормозить, что дурной :) .

БредятинаEmery Вы знаете мои проблемы лучше меня :) ?
Скорее всего:) Иначе, я бы не стал публиковать сообщения в этой теме.
Тогда может быть Вы знаете и их решения :) ? Почему бы Вам не поделиться?

БредятинаВы заметили на какую тему переключились?:) Это уже не про способ хранения данных...
Без УК очень тяжело полноценно реализовать предлагаемую модель хранения данных. Поэтому приходится говорить и об универсальном клиенте.

БредятинаА бизнес-приложения программировать - это просто нонсенс:) Их уже давно пора прекращать программировать. Так что даже хорошо, что Вы, хотя бы временно, их не программируете. Вот и сделайте так, чтобы никогда их не программировать.
Я под «бизнес-приложениями» понимаю, в данном контексте, программирование учета на предприятии. Видимо Вы подразумеваете что-то другое. Думаю, надо обращать внимание на контекст разговора также.

БредятинаEmery (не зря фирма «1С» называет справочники «условно-постоянной» информацией)
Зря:) Оба понятия (и "справочник", и "условно-постоянная информация") не имеют никакого практического значения для управления данными.
«Справочник» - синоним первичной таблицы данных, а «условно-постоянная информация» означает редко изменяемую историю модификации полей этой таблицы. Можно обойтись без синонимов, только речь тогда будет перегружена одинаковыми терминами.

[quot Бредятина]Emery Документы не должны содержать периодических реквизитов. После их проведения, все ссылки замещаются их значениями на время проведения и данные документов фактически замораживаются.
Какими еще "значениями"?:) Например, у материала (используемого в любой операции движения) может быть несколько десятков ("редко изменяемых", как Вы говорите) характеристик, и соответственно, есть их значения "на момент проведения". Они что, записываются в "документ"?:)
В документ могут и не записываться, чтобы не перегружать его ненужной информацией, но фиксация данных подразумевается. Например, я дал вам бутылку свежего пива по Вашей просьбе, а Вы мне возвращаете его несвежим, мотивируя, что за это время оно испортилось. Характеристика то его изменилась со временем. Это так, но операция перемещения бутылки пива от меня к Вам зафиксировала его свежим, вот и Вы должны вернуть его свежим, даже если за это время оно могло испортиться. Надеюсь, аналогия понятна?

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

БредятинаEmery «Универсальный клиент» это конфигурируемый интерфейс представления данных без привязки этих данных к источнику данных.
Какую модель данных Вы предполагаете использовать в этом слое?
Я писал уже, что несколько. Сначала попробую ту, что описал в начале темы (некую конкретизацию EAV). Если она не подойдет, то использую усовершенствованную модель данных, которую я применяю в своих конфигурация, ну и затем, для сравнения, некий вариант клиент-серверную модели. В любом случае УК должен быть одним и тем же.

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

БредятинаEmery Т.е. программист сам делает запросы к Серверу БД на основе уведомлений (желательно) виртуального режима представления данных Универсального Клиента. Где-то так :) .
Искренне надеюсь, что это какая-то опечатка:) Программист не дожен "делать запросы". Разве это не очевидно?:)
«Делать», в смысле «программировать», «разве это не очевидно» :) ?

egorychEmeryЯ не знаю случая из своей практики, чтобы нужна была история модификаций полей данных с точностью меньшей, чем сутки.машина въехала на терминал вчера в 23:59 или сегодня в 0:01 - результат: <сумма штрафа>= <много>:0
PS Emery - известный велоипедостроитель, его бы энергию. да в мирные цели... но учиться не хочет, верит в одынцэ
Да, нетушки! Тут уже Вы прокололись! То, что Вы описываете, является операцией, регистрируемой во вторичной таблице отношений. А в таблице операций, сами операции регистрируются с точностью до минуты (об этом я уже писал в этой теме несколько сообщений назад), хотя допустимо и до секунды, что не принципиально. Вторичные таблицы (отношений, операций, документов) должны быть всегда «двухмерными», т.е. без истории модификаций полей. А первичные таблицы (определений) могут быть и «трехмерными», т.е. с историей модификации полей. А здесь точность меньше суток практически не востребована.