To: Сергей Васкецов

> Очевидные вещи тем и хороши, что их легко доказать.

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

> Тогда вообще говоря единичного преобразования может в принципе не быть.

Речь вообще не шла, об отображении пространств и я здесь вообще не строю теорию, просто попутные соображения, которые вы волны игнорировать.

> Речь шла о тождественном преобразовании

Синоним единичного преобразования

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

Разве я должен делать все это в этой ветке? Возможно после окончания своего проекта, я выложу развернутую информацию на своем сайте в Интернет.

> Это что, 1С? Я просто с ней знаком очень слабо. В любом случае, речь не о том, что "не пользуйтесь
> чем-то, и тогда все получится", а "система вообще не имеет проводок как таковых". Даже при всем
> негативном отношении к 1С, думаю, до отказа от проводок они не додумались. Если Вы правы,
> многие старшие товарищи подтвердят, что проводок в 1С нет.

Да это 1С. «Не пользуйтесь» потому, что можно делать проводки либо через документ, либо вручную, так называемый документ «Операция». Для некоторых документов нет проводок, например для учета уставного капитала («БУ для Украины»), но если вы ведете учет уже действующего предприятия, то очень часто можно обойтись без ручных проводок совершенно. Проводки в 1С ЕСТЬ! Там без них нельзя в принципе (модель учета Нуралиева не позволяет!)

> Что ж Вы тогда отстаиваете ненужность проводок?

Вы не очень внимательно читали мои сообщения. В моей программе они тоже есть, только система регистров и журнал проводок у меня реализован на подчиненных справочниках, а не так, как хочет Нуралиев. Ненужность проводок я аргументирую для чистых клиент-серверных систем (с SQL-сервером хотя бы). У меня же файл-сервер – это значительно дешевле и удобней, а для средних предприятий более чем достаточно (на движке VFP8).

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

Все так, что ж тут непонятного?

> Это спорное (а с моей точки зрения просто глупое) положение видимо и есть корень зла.

Корень зла чего?


> Пример - экспорт платежек в банк. Вы экспортируете черновые платежки?

Нет, не экспортирую. Для чего? Я пишу комплексную конфигурацию для ведения полного учета на предприятии, в том числе производства. Экспортировать мне не для кого.

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

Для этого существует «Выписка банка». По ней происходит реальное движение денег по банку. Поверьте, у моего универсального документа достаточно параметров для отслеживания ситуации.

> Еще пример - разграничение полномочий. Приходную накладную утверждает кладовщик (МОЛ).
> Проводки по ней - бухгалтер (например, в конце месяца, если позволительно). Каждый проверяет
> информацию и несет ответственность за свою часть. Кладовщику не интересно, какой счет
> хранения, бухгалтеру не интересно, куда это положили.

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

> Вот именно по этому я и просил в терминах реляционной алгебры, а не на пальцах.

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

> Тогда все будет четко и ясно, и я Вам покажу место, где у Вас ошибка в рассуждениях.

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

To: Сергей Васкецов

>> Из всего вышесказанного это должно быть очевидно. Нарушает 3-й принцип нормализации базы данных

> Давайте начнем с простого. Догадываетесь, почему я выделенные слова выделил?
> Можете привести этот принцип?

Конечно, могу.

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

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

Вторая нормальная форма. Отношение R (A1, ..., An) находится во второй нормальной форме (2НФ), если оно находится в 1НФ и если каждый не первичный атрибут функционально полно зависит от каждого возможного ключа. (Определение полной функциональной зависимости. Пусть имеется функциональная зависимость: {X1, X2, ..., Xn} Y. Если из множества атрибутов, стоящих слева от знака , можно исключить некоторые имена атрибутов без разрушения функциональной зависимости, то говорят, что Y зависит от множества {X1, ..., Xn} неполно. В противном случае, имеет место полная функциональная зависимость атрибута Y от множества атрибутов {X1, ..., Xn}.)

Третья нормальная форма. Отношение R находится в 3НФ, если оно находится в 2НФ и в нем нет транзитивных зависимостей атрибутов от возможных ключей, т.е. каждый не первичный атрибут не транзитивно зависит от каждого возможного ключа отношения.
Третья нормальная форма не допускает ФЗ (функциональной зависимости) между не первичными атрибутами отношения, так как это создает транзитивную зависимость не первичных атрибутов от ключа.
Более точно правило принадлежности отношения к 3НФ можно сформулировать следующим образом. Выделим из множества имен атрибутов АR отношения R три подмножества X, Y, Z, не являющихся атрибутами ключа, так что X -> Y и Y -> Z.
Если XY, YZ и YX, то Z транзитивно зависит от X, т.е. XZ и ZX
Заметим, что запрещается только ФЗ YX, так как в этом случае они бы функционально определяли друг друга (что фактически соответствовало бы их эквивалентности). Наличие или отсутствие ФЗ ZY в данном случае игнорируется: она может как существовать, так и не существовать.
Переход к отношениям в 3НФ осуществляется путем построения проекций исходного отношения R. Такой переход может быть не единственным, поэтому вводят понятие оптимального разбиения исходного отношения на проекции в 3НФ. При этом принято считать, что если количество отношений, находящихся в 3НФ, минимально, то разложение оптимально.

Усиленная 3НФ (БКНФ – Нормальная форма Бойса-Кодда)
Отношение со схемой R находится в нормальной форме Бойса - Кодда относительно функциональных зависимостей, если оно находится в третьей нормальной форме и в схеме R нет ни одного атрибута, транзитивно зависящего от любого ключа.
Существуют и другие определения усиленной 3НФ (У3НФ). Например, Нормализованное отношение находится в У3НФ, если каждая детерминанта является возможным ключом.
Под детерминантой понимают некоторый атрибут (возможно составной), от которого функционально полно зависит какой-либо другой атрибут.

Четвертая нормальная форма. Отношение R(AR) находится в четвертой нормальной форме, если в структуре МЗ (многозначная зависимость), определенной на множестве атрибутов AR, имеются только тривиальные МЗ зависимости и/или такие нетривиальные МЗ, что левая часть любой из них является ключом R. Определение МЗ. Пусть R(X, Y, Z) - схема отношения R, Х, Y, Z - непересекающиеся подмножества атрибутов R, и пусть Z = AR\ (X, Y). Отношение R удовлетворяет МЗ XY, если для двух любых кортежей t1 и t2 из Ri, таких, что t1(x) = t2(x) (т.е. кортежи t1 и t2 совпадают по значению х) в Ri существует кортеж t3 такой, что t3(x) = t1(x), а t3(у) = t1(у) и t3(z) = t2(z). Из симметрии определения относительно t1 и t2 (учитывая, что t1(x) = t2(x)) следует, что в Ri существует также кортеж t4, для которого t4(x) = t1(x), t4(y) = t2(y) и t4(z) = t1(z).
Фактически определение 4НФ следует из теоремы Фейджина. Отношение R (A, B, C) можно спроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и только в том случае, когда существует MЗ A B | C. Под проецированием без потерь здесь понимается такой способ декомпозиции отношения, при котором исходное отношение восстанавливается путем эквисоединения полученных отношений с отсутствием ловушки соединения и сохранением структуры зависимостей.

Пятая нормальная форма. Отношение R находится в пятой нормальной форме (нормальной форме проекции-соединения - PJ/NF) в том и только том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.
Существует и другое определение 5НФ, принадлежащее Фэйджину. Отношение R находится в 5НФ тогда и только тогда, когда каждая зависимость соединения подразумевается потенциальными ключами отношения. Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем декомпозиции. Заметим, что зависимость соединения является обобщением, как многозначной зависимости, так и функциональной зависимости и на практике ее выявить достаточно трудно.

> Так что насчет травы я может и прав был.

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

To: Сергей Васкецов

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

Вы, случайно не преподавателем работаете?

> Очень часто, когда попытаешься доказать очевидную вешь, становится понятно, что
> она не такая уж и очевидная.

Вот и я про то же. Про это знали еще древние греки. Не мало легенд пришло из того времени. К чему углубляться в дебри философии? Все в этом мире относительно и очевидность и доказуемость, особенно неформальных вещей, к которым в значительной мере относиться и программирование. Я привык общаться с людьми, которые, прежде всего, обращают внимание на суть высказывания, а не на его форму. Если Вы хотите пофилософствовать, то вот Вам задачка по философии. Согласно материалистической диалектике, все в этом мире развивается, движется, находится в развитии. Вопрос. Развиваются ли, изменяются ли законы, управляющие этим развитием? Хотелось бы получить ответ в форме да / нет. Мы можем поспорить о первичности курицы или яйца (без подколки, вполне серьезный вопрос), об эволюции или божественном создании всего живого, о том, помнит ли материя о своем прошлом и т.д. Это все достаточно интересные вопросы, но место ли им здесь?

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

Ну, я не знаю, что сказать : ) . Я то как раз и использую проводки, которые строю на основании операций документов. Ибо честно использую файл-серверную технологию. Когда буду использовать чистую клиент-серверную технологию, тогда явных проводок у меня не будет. Но это если будет крупный заказ на крупном предприятии. Сейчас на моей фирме всего 1000 человек, использовать SQL-server я не вижу необходимости.

> Вы говорите о нормальных формах? Что за принципы?

Я привел формулировки всех принципов, в предыдущем сообщении.

> Нет. Мне дела нет до Вашей программы и как она работает. Тем более что в ней есть
> проводки. Просто Вы (а может и не только) видимо настолько неверно интерпретируете
> реляционную теорию, что у Вас выходит, что пара (документ+проводка) нарушают
> нормализацию. Вот я и прошу привести эти самые мифические "принципы
> нормализации БД".

Проблема, в общем-то, в одном. Вы согласны, что документ с операциями + проводки дают избыточность базы данных? Либо да, либо, нет. Если да, тогда остается только доказать, что принципы нормализации эквивалентны не избыточности данных, для установки противоречия. Если нет, тогда нужно брать Вашу базу данных и так ее преобразовывать, чтобы доказать, что ее можно уменьшить в объеме, за счет динамического вычисления проводок, в момент их использования, без потери информации. Возможно, при этом она станет медленней работать, если Вы не используете SQL-сервер или что сопоставимое с ним. Пожалуй, этот путь слишком трудоемок для меня, чтобы я за него взялся. Скорее всего, Вы останетесь при своем мнении, а я при своем. Что, видимо, не помешает нам писать собственные программы, в соответствии с своими принципами.

Откровенно говоря, я не понимаю Ваших наездов. Ну, хорошо, допустим, правы Вы, а я неправ. Ну и что? Ваши программы будут более эффективны и конкурентоспособны, мои менее. Я достаточно много сказал информативных вещей о своей программе. Скажем о том, как из 1С подключится к runtime-библиотеке Visual FoxPro мало кто знает даже в Интернете. Про универсальную форму документов в учете ресурсов (в том числе, учета производства), я вообще ни от кого не слышал. Ладно, про универсальный отчет была идея, но хороших реализаций я не знаю. Неужели не интересно об этом поговорить? Об эквивалентности принципов нормализации принципу минимальности. Это мои собственные размышления. Возможно, я не прав, но давайте говорить по существу, а не цепляться к словам. Неужели, не понятно, что нарушение принципов НФ, это не всегда плохо? Теряем в одном, выигрываем в другом. От Вас же я мало, что услышал информативного для себя. Да, я понял Вашу позицию, вполне допускаю право на ее существование, но совершенно не понимаю, почему Вы так агрессивны? Не нравится, что пришел некий дядя и начал умными словами к месту и не к месту раскидывать с самоуверенным видом? Типа, надо поставить чувака на место? Даже если так, уместно высказывание древних: «Юпитер, ты сердишься, значит, ты не прав!»…

To: leonidy

> Вы вопрос забыли как звучал? Напоминаю:Что такое проводка и зачем она?

Могу также присоединиться к реплике Сергея Васкецова на Ваше замечание. Ответ уже был дан неоднократно и с различных точек зрения. На мой взгляд, тема закрыта. Другое дело, что попутно стали говорить о других вещах, мнение о которых вызывает споры.

Что же до Вашего определения:

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

то оно хотя и правильное, но бесполезное для программиста, пишущую соответствующую программу учета. Это определение для бухгалтеров, чтобы они знали, что говорить на экзаменах. А «словоблудие» развели программисты-практики, которые непосредственно должны объяснить машине, что такое «неделимая операция, отражающая… изменение … объекта учета». Это слишком общо, чтобы быть достаточно информативным. А спорим мы, по сути, об эффективности разных подходов программирования. Вот ответьте, на основании Вашего определения, нарушают ли проводки принципы нормализации базы данных? Сергей Васкецов говорит нет, я говорю да. А Вы что скажите?

To: OA User

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

> Суха теория... :)
> Вы рассуждаете с позиции программиста, проектировщика БД, но никак не
> пользователя.

Интересный Вы, товарищ! Да я ведь не франчайзи 1С, который продал коробку с 1С, а там хоть трава не расти. У меня конкретное задание, внедрить на собственном предприятии любую программу, лишь бы работала как надо. Никто даже не заставлял меня писать свою собственную. Просто перепробовав множество программ, я пришел к выводу, что можно реально внедрить и отвечать только за собственную. В чужих программах так много даже грубых ошибок, которые невозможно поправить, не будучи на узде у ее автора. Может быть, где-то и существуют идеальные программы, но я про них не знаю. Здесь как раз тот случай, что быстрее сделать свою, чем найти чужую. Лично самый большой пользователь это я сам, ибо мне мало чтобы программа работа как-нибудь, мне должно быть комфортно с ней. А при внедрении и сопровождении мне приходится работать с ней неоднократно.

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

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

To: leonidy

> Мне вообще непонятно зачем программисты практики обсуждают принципы
> нормализации(денормализации).Мне кажется энто сильно зависит от конкретики.

Можно ведь и не обсуждать, тем более что большинство не обсуждает. Только вот почему тогда так много плохих программ (для определенности, по учету на предприятии) и так мало хороших? Почему 1С8х такая прожорливая на ресурсы и таким низким кпд? Тем более что кое-что в ядре 1С77 сделано почти идеально. Почему собственные программы работают не всегда как надо? И не потому, что у программиста кривые руки, а потому, что с концепциями программирования он плохо знаком. А принципы нормализации это только небольшая часть, что нужно знать программисту...

To: Александр Федоренко

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

> Можно встрять в ваши "разборки" со своим имхо?
> Проводка (если конечно идет разговор НЕ о "проводке" документа) понятие бухгалтерское и само по
> себе не может нарушать принципы нормализации базы данных. Надо говорить о конкретных
> реализациях этого "явления".

Речь, шла о том, что в чистых клиент-серверных приложениях можно обойтись без предварительных проводок, в т.ч. бухгалтерских. А вычислять их непосредственно в момент использования, не занимая места в базе данных. Что это, как ни минимизация общего объема базы данных? И если доказать, что минимизация эквивалентна нормализации (пака это только мое предположение), то получим, что избыточные базы данных нарушают нормализацию, что само по себе не есть зло. Вспомним хотя бы таблицы Excel. Это ведь не базы данных, которые если и удовлетворяют, то только принципу 1НФ. Но разве от этого они менее полезны?

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

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

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

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

To: Сергей Васкецов

> 1. Первая Ваша ошибка (небольшая, потому что, уверен, все, кто хотел, сразу ее уловили) - это то, что
> нет принципов нормализации, есть приведенные Вами нормальные формы. Форма - это что-то типа
> проверки, то есть, анализ постусловия.

Хорошо, допустим, Вы правы! Тогда вопрос. Зачем нужна эта проверка, анализ постусловия? По-Вашему, что-то типа ненужное. Но по логике (Вы же логик!) она должна иметь смысл. Скажем, критерий оптимальности базы данных. Ведь даже на интуитивном уровне базы данных могут быть хорошо структурированы и плохо. С плохими базами данных тяжело работать, ниже к.п.д, выше процент ошибок и т.д.

> Принцип нормалиации - это алгоритм приведения к требуемой нормальной форме.

Можно ведь понимать и по другому. Способ сразу так строить связи и структуру БД, чтобы с ней можно было максимально эффективно работать. Чтобы БД была не эксело-подобной, а полноценной. Я ведь могу проектировать базы данных по-разному. И две одинаковые БД, но с разной структурой можно ведь сравнивать по эффективности работы, по гибкости ее использования. По-Вашему, принципы НФ не имеют никакого смысла для оптимизации проектирования БД. Пусть так. Но у меня другое мнение, которое практикой пока что не опровергается, скорее наоборот.

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

Не логично! С чего Вы взяли, что принципы нормализации должны применяться к «полностью денормализованным структурам данных»? А не частично нормализованным, тем более, что далее Вы уже это имеете в виду, говоря о «повторении этого принципа с самого начала» после «добавления» даже «одного поля».

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

Это совершенно не из чего не следует! Не скажу, что я уж очень рьяный сторонник формальных теорий по базам данных, больше предпочитаю работать по собственным понятиям, хотя и с оглядкой на основные идеи БД. Для себя я вполне такие критерии сформулировал. И даже если они не совсем правильны и точны, для меня они вполне работоспособны и применимы. Данные я делю на первичные и вторичные, в том числе и таблицы. Второй и третий принципы нормализации (первый - атомарность данных) я формулирую для себя так: 2. Вторичные данные (таблицы) не должны содержать в себе первичные данные (таблицы); и 3. Первичные данные (таблицы) не должны содержать в себе вторичные данные (таблицы). Может быть, для Вас это будет словоблудие (Вы же собственные принципы не демонстрируете), однако для меня они вполне понятны и применимы, даже при всей их не строгости. Отсюда, кстати, легко получаем принцип минимальности БД. Думаю, что существуют более продвинутые теории в этой области, но мне пока хватает собственных наработок.

> 2. Вторая Ваша ошибка для Ваших рассуждений фатальная. В определении нормальных форм нигде
> не говорится про базу данных вцелом, только об отдельных таблицах (в терминах РСУБД). Именно
> поэтому реляционная алгебра (а именно эта часть реляционной теории имеет строгую
> математическую основу, все остальное - околонаучная болтовня) ничего не знает про множество
> таблиц в БД.

Как ни странно, без реляционной алгебры вполне можно жить. Я полагаю, хотя и без претензии на истину, что реляционная алгебра нужна была только для одного, для обоснования систем разработки реляционных (табличных) баз данных. Ведь история промышленности знает огромное множество реализаций баз данных как таковых. Вспомним хотя бы иерархические базы данных (система MSM). Но в итоге выбор промышленности остановился на реляционных БД, насколько я понимаю, благодаря реляционной алгебре, которую, если я не ошибаюсь, создал Кодд в 60-х годах. Все, далее, она уже особо не нужна, ибо современные системы разработки БД вполне основаны на ее принципах. Как ни странно эти же системы разработки смотрят на БД, как единое целое, с поддержкой различных механизмов целостности. Эти механизмы не следуют из реляционной алгебры? Допустим даже так, но тогда они следуют из чего-то другого. Когда это будет для меня критически важно, я проясню для себя этот вопрос.

> И именно поэтому даже наличие полностью идентичных таблиц в БД не нарушает их (таблиц!)
> нормализации (потому что, строго говоря, нет такого в принципе термина "нормализация БД" и
> именно поэтому "классическая" денормализация - это денормализация "в одной таблице", например,
> как если бы сложили результат select * from ... join ... в таблицу).

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

> А если Вы ввели собственный термин нормализации БД и считаете его соответствующим критерию
> минимальности размера БД, то практического применения такой критерий все равно не имеет. Размер
> БД в конечном итоге влияет только на размер ее дампа, время поднятия на сервере и время
> выполнения сервисных операций и ни на что более.

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

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

To: leonidy

> И оставьте этот бессмысленный и беспредметный разговор.Займитесь делом наконец:)

Это не проблема. Разговор прекратится, как только уйдет последний заинтересованный собеседник. А к этому все идет : ) . Что же до дела, то смею Вас заверить, что здесь я тусуюсь исключительно в качестве разгрузки после тяжкого программирования : ) . У меня все неплохо получается, поэтому нет повода менять что-то кардинально. А что до споров, то свои идеи, я не кому не навязываю. Мое дело предложить, а «ваше» дело отказаться. Сам я чужие идеи вполне воспринимаю, если вижу в них что-то полезное для себя.

То, что в «бессмысленном и беспредметном разговоре» есть смысл, я продемонстрирую на Вашем же примере:

> Это убожество,открывающее до 400 файлов за одну сессию я снес у себя даже не обращая на
> привлекательную цену и замечательную коробочку с описанием ,помнится что-то около 70 у.е.
> было заплачено.

Так думают большинство программистов, не давшие себе труд вникнуть в суть вещей. Если 1С такой плохой, то почему:

> При этом конкурентов у 1С на небольших предприятиях в принципе нет.1С надолго и всерьез ,
> надо-же а кто-бы мог подумать каких нибудь 10 лет назад.

Почему не MS Access, не Visual FoxPro, ни Delphy, ни Visual Studio? Список можно продолжать и продолжать. Неужели все дело только в навязчивой рекламе? Не удивлюсь, если Вы даже найдете какой-то ответ, со своих позиций. Но, если смотреть правде в глаза, то 1С, не такой уже и плохой.

На эту тему я выступал неоднократно, не хочется сильно повторяться. С 1С можно иметь дело, если увидеть его сильные стороны и не использовать слабые. Не буду обосновывать, свои взгляды (читайте мои предыдущие сообщения), скажу главный вывод. Использовать нужно только часть ядра 1С77 и никаких типовых конфигураций. А именно, систему ввода – конфигурируемый интерфейс справочников, систему вывода – экселоподобную систему отчетов 1С и внешнее ядро базы данных Visual FoxPro (всего 3-4 dll-ки). Плюс некоторые внешние компоненты для большего марафета. Система получается супер! Дешевая, производительная, комфортная (при правильном программировании конфигураций) и что самое главное это система быстрой разработки. Я пришел к этому мнению сам, и думаете, создал бы подобную систему, если бы не вникал в смысл вещей? Я один пишу полный учет для типичного учета на среднем отпово-производственном предприятии. И это всего 3-4 человеко-лет трудоемкости. Ну, назовите мне сопоставимую систему по цене, удобству использования, возможностям и скорости разработки подобную вышеупомянутой. Мне достаточно безразлично, на чем пишут программы другие, я просто говорю: люди, те, кто мучаются с выбором системы программирования, не морочте себе и другим голову по поводу 1С-плохиша, программируйте как я! Но нет, чужие идеи нам не интересны, мы лучше будем набивать себе шишки на собственных бзиках. Да ради Бога! Пишите как хотите, я уже говорил, мое дело предложить… Вот сейчас уже существуют несколько альтернатив 1С (с конфигурируемым интерфейсом). «2С», «Ананас», «Алькорд-Афина», «SMarket v. 4» и т.п. Для некоторых систем даже существуют открытые исходные тексты. Но, видно, что народ явно тяготеет к «неправильному» программированию, типа того, по которому пошла 1С8. А уделяли бы больше внимания «бессмысленным и беспредметным разговорам», меньше делали бы глупостей. Но, как говориться, нет пророка в своем отечестве.

> Сначала давайте определимся ,что значит плохая программа?

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


> А мне кажется ,что с точки зрения 1С-франчайзи например .1С супер программа -вечный
> двигатель.Вы даже не представляете сколько народу кормится благодаря этой проге.И заметьте
> не плохо кормится!

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

> И принципы нормализации здесь не работают совсем хоть ты тресни.Я уж не говорю про концепции
> программирования:).

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

> По поводу производительности у microsoft кстати очень схожая позиция.Если железо не тянет -
> КУПИ себе НОВОЕ железо.И это правильно.Пользователь конечный ни черта не смыслит в
> концепциях программирования нормализации и производительности.Ему нужен инструмент для
> решения вполне конкретных задач.

Их подход я знаю. Так от пользователя ничего и не требуется. Пользователю моих конфигураций достаточно пол-часа объяснений, чтобы начать работать. Да, под мои контролем, зато от них не требуется ничего, кроме уровня девочки после 10 классов. Все остальное это мои проблемы. Для самостоятельной работы программы, нужен будет продвинутый администратор, который бы хорошо понимал, что к чему…