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

(0) излишняя нормализация - вред

(0) Все не успокоишься? В чем смысл твоих вбросов?

Требования нормализации не соблюдаются в критически важных таблицах 1с – бухгалтерских итогов, проводок. Бухгалтерские итоги по всем счетам хранятся в одной таблице, без разбиения на разные таблицы в зависимости от типа аналитики счета, а ведь разные счета хранят разные по структуре данные! Например на счетах взаиморасчетов (60, 62, 76 бух. счета) хранится информация по следующим измерениям (субконто): контрагенты, договора, документы. А на счетах учета материалов (10 счет) – по номенклатуре и складам. Как следствие в таблицу итогов кроме полей «субконто», вводятся поля «тип субконто» (??? А может и не вводятся, а если и вводятся только для неопределенных полей. Нужно проверять таблицы в MS SQL, в 8 версии вроде переделали). Соответственно к индексам введенным для субконто, вводятся еще индексы для полей «тип субконто». В случае плана счетов с максимальным количеством субконто к счету равным 3, количество индексов в таблице бух. итогов вместо 4 (3 для трех субконто и 1 для счета) становится 7 (дополнительно еще 3 для типа субконто). Это может существенно влиять на производительность, с учетом того что все документы формирующие бух. проводки будут формировать записи в данной таблице. Также существенным минусом является то, что количество полей-субконто одинаково для всех счетов, ведь как уже было сказано остатки по всем счетам хранятся в одной таблице. Считается нежелательным добавлять больше 3 субконто к счету, а в 7.7 вообще невозможно было больше 5 создать, это было ограничение платформы. Кроме того, по сути невозможно добавить поля в таблицу движений конкретного счета (она ведь одна на все счета). Также невозможно сделать RLS (ограничение доступа к данным на уровне конкретных записей а не всей таблицы) по бухгалтерским остаткам и движениям. Данные ограничения, возможно, привели к созданию множества различных дополнительных регистров другого типа - не бухгалтерских (не использующих корреспонденцию), например, для учета операций по НДС. Эти регистры независимы друг от друга, и в них можно создавать необходимое количество измерений, полей.
- Сомнительно использование механизма характеристик для торговой и прочей деятельности. Смысл характеристики в том, что в поле документа или регистра остатков хранится не ссылка на справочник например размеров одежды или цветов одежды или страны-производителя и пр., а ссылка на запись другой таблицы (назовем ее ТаблицаХарактеристика), к которой подчинены несколько записей другой вспомогательной таблицы, где и хранятся типы и значения разных атрибутов – размеры, цвета, страны-производители, веса, габариты, по сути что угодно. В этой вспомогательной таблице есть поле «Вид свойства» (ссылка на справочник свойств, значения данного справочника – цвет, размер, страна и т.п., их можно сколько угодно создавать) и поле «Значение свойства» (например красный, синий, зеленый для цветов; 40, 41, 42 – для размеров и т.п.). Но для того чтобы хранить данные например о двух цветах и трех размерах нужно завести все возможные комбинации используемых цветов и размеров. Например Белый 42 размер, Белый 43 размер, Белый 44 размер, Синий 42 размер, Синий 43 размер, Синий 44 размер. Т.е. вводится большее количество записей в таблицы, чем есть в реальности – на два цвета и три размера (итого 5 записей) вводится 6 записей! Для трех цветов соотношение будет уже 6 к 9. По-видимому данный механизм 1С придумала для того, чтобы пользователь при отсутствии программиста мог сам добавлять произвольные характеристики (например товаров) используемые в данной организации или для того чтобы не вносить изменения в конфигурации из-за дополнительных свойств. Но во-первых обычный пользователь вряд ли сможет самостоятельно заполнить характеристики (скорее всего он про них и не знает), а во-вторых если приглашается программист, то ему по сути проще и правильнее добавить несколько колонок (в нашем примере цвет, размер) в несколько таблиц (приход, расход, остатки) и прописать их в движениях, чем использовать характеристики, а потом доделывать отчеты чтобы характеристики показывались в удобной форме и в-третьих программисты 1с уже есть во всех городах страны, возможно уже в деревнях есть, так что нет никакой проблемы вызвать программиста и доработать конфигурацию. И самое главное, очевидно характеристики ведут к проблемам с производительностью, удобством выбора значений (автопоиск значения по первым введенным символам не работает), а также усложнению конфигураций, т.к. приходится дорабатывать отчеты и различные модули под характеристики. Характеристики можно рассматривать как пример антипаттерна из классических трудов по программированию, где рассматривается ошибочное решение и к каким проблемам данное решение приводит. В данном случае возникающие проблемы – существенны, а заявленные плюсы – сомнительны. Регистр расчетов – вообще непонятно зачем нужен. А перерасчеты не всегда нужны, нужно выдавать лишь предупреждение о пересечении исключающих видов расчетов, зачастую нужно отменить невыход или другое событие, а не делать его перерасчет.
- Ошибки есть не только на уровне платформы, множество сомнительных решений допускается при проектировании типовых конфигураций. Например таблица адресов – поля нессылочные, просто записывают текст "г. Москва", вместо ссылки на справочник городов. То же самое с областями, улицами. Очевидно это нарушение принципа реляционности. К тому же нарушаются принципы нормализации, т.к. поле город однозначно идентифицирует регион, следовательно поле регион избыточно в таблице адресов (конечно в случае хранения ссылочного поля «город»). Ссылочный тип дал бы возможность простого анализа продаж по типам регионов, городов и т.д. Но и это еще не все. В таблице адресов хранятся не только адреса, но и телефоны, e-mail, по сути там мешанина данных как и в таблице бухгалтерских остатков. Аналогичные проблемы с адресами физлиц, т.к. они хранятся в той же таблице что и адреса контрагентов. Вся эта мешанина привела к созданию целого модуля для работы с контактной информацией, по сути ненужного. При этом рекомендую всем посмотреть данный модуль для работы с адресами. Сложность его не соответствует решаемой задаче (см. пункт 1). Можно конечно попробовать возразить, что соединения таблиц может быть ресурсоемким в случае больших таблиц и поэтому хранится не ссылка, а текст "г. Москва", но в данном случае скорее всего данные таблицы не настолько велики. Также нужна история адресов, ведь адреса могут меняться. Возможно не нужно поле контрагент в различных таблицах, если есть поле договор в той же таблице, ведь договор однозначно идентифицирует контрагента (это спорное утверждение).
- Во все справочники ТК добавлен автоматически нумеруемый реквизит «Код» (причем не всегда уникальный), при создании нового справочника в конфигураторе также по умолчанию создается данный реквизит. Хотя для большинства справочников он не нужен. Он может понадобиться разве что для справочника Основных средств, Номенклатуры, да и то только под названием «Инвентарный номер», а также справочника «Сотрудники» под названием «Табельный номер». Интересно, какой процент программистов 1с задумывался над данным вопросом? Конечно вряд ли данный реквизит существенно влияет на производительность, но определенные неудобства может создавать когда сбивается нумерация (как правило 1с контролирует уникальность данного реквизита). Непонятно зачем в ТК при нумерации кодов в справочниках и номеров в документах к числу добавляются нули, например 000245. Это приводит к определенным проблемам при штрих-кодировании, когда появляются разные номенклатуры с кодами различающимися только ведущими нулями, ведь при печати штрих-кода нули удаляются, а при сканировании соответственно уже невозможно правильно идентифицировать номенклатуру отличающуюся только количеством ведущих нулей.
- В качестве ключевого поля (уникального идентификатора) для таблиц используется поле типа GUID, хотя в 7.7 версии хватало поля числового типа. Очевидно в большинстве случаев хватит числового идентификатора. Вероятно использование GUID отрицательно влияет на быстродействие соединения таблиц в запросах, на создание, запись и проведение справочников, документов. С данным полем достаточно неудобно работать в 1с. К тому же вряд ли получится использовать GUID-поле для штрих-кодирования например номенклатуры или основных средств. Полагаю это достаточно редкое решение при построении баз данных – использовать GUID-поле в качестве ключевого поля.

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

(0) Ну все убедил. Показывай свою убийцу 1С

(3) утренняя порция словесного поноса

(3) много букв, местами бред, это твое или копи-паста?

(0)Иногда разумно жертвовать нормализацией для обеспечения приемлемой скорости доступа к данным. Это во-первых.
Во-вторых о таких вещах не рассуждают сразу после того как прочитал учебник. Надо сначала переварить информацию и посмотреть на практическое применение теоретических правил.

(0) И чего. В "крутых" системах лучше что ли? Вон Манхеттен какой нибудь например - там вообще наименование товара в куче таблиц хранится - независимо друг от друга... И ниче, продают и внедряют за десятки млн руб, не жужат

(7) Копипаста. Причем древняя.

(10) где копипаст ты увидел? давай ссылку.

уже сколько лет эту тему обсасывают..
каждый, кто теорию баз данных для себя уяснил, стремится показать высокий уровень собственных знаний путем забрасывания 1С пахучей субстанцией..

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

(0) я тебя не могу понять! Не нравится, не пользуйся! Есть альтернатива. Нафига ты сюда пишешь?

(14) да нет альтернативы, поэтому и пишу. Хочется чтобы наверху услышали

(15) ну дык, ВВП сейчас на прямой связи...

Да регистр бухгалтерии это та еще бяка.
(13) А хрен ли, в умных книжках написано что если Вам нужна мегааналитика и скорость обработки данных. Пользуйте РН/РС и все тут баста.

(15) почему нет? Бери любой язык программирования + любая СУБД и создавай ИБ для расчетов. Какой верх? Тут на форуме верхи не сидят и им как бы всё равно.
(16) прикинь, звонок в прямой эфир и ты начинаешь лечить что в 1с нет нормалицазий, через минуту звонок в дверь и выходи с вещами на выход.

вторая ветка сегодня, где встречаю слово "гуру"
обе ветки необыкновенно хороши

(19) это про тебя он пишет?

(0) Маня?

(15) Зачем?

(0) А СУБД мс скль очень неоптимизированно использует дисковое пространство. Срочно надо его убивать!!!!

+(23) это сказывается на доступе к данным на диске, а так-же уменьшает срок эксплуатации железа

вместо (3) - http://realprog.livejournal.com/665.html

> В качестве ключевого поля (уникального идентификатора) для таблиц используется поле типа GUID, хотя в 7.7 версии хватало поля числового типа. Очевидно в большинстве случаев хватит числового идентификатора. Вероятно использование GUID отрицательно влияет на быстродействие соединения таблиц в запросах, на создание, запись и проведение справочников, документов. С данным полем достаточно неудобно работать в 1с. К тому же вряд ли получится использовать GUID-поле для штрих-кодирования например номенклатуры или основных средств. Полагаю это достаточно редкое решение при построении баз данных – использовать GUID-поле в качестве ключевого поля.

В 7.7 использовался ID. И он строковый, а не числовой. И собственно чем Вам GUID не понравился? Религия? В чем неудобство работы? По сути Вы вообще с ним не работает, а работает движок. За редким исключением. Причем здесь штрихкодирование? С чего Вы решили, что штрикод имеет номенклатура, а не ее партия, упаковка или еще какая-то хрень? В чем редкость явления использования идентификатора строкового типа в таблицах?

Бредятина какая-то...

+(24) и вообще. включаете компьютер - а он от этого изнашивается!!!
надо комп в сторону отставить, выключить, накрыть красивой салфеткой, сверху горшок с геранью - а буху тетрадку и счеты :)))

> Во все справочники ТК добавлен автоматически нумеруемый реквизит «Код» (причем не всегда уникальный), при создании нового справочника в конфигураторе также по умолчанию создается данный реквизит. Хотя для большинства справочников он не нужен. Он может понадобиться разве что для справочника Основных средств, Номенклатуры, да и то только под названием «Инвентарный номер», а также справочника «Сотрудники» под названием «Табельный номер». Интересно, какой процент программистов 1с задумывался над данным вопросом? Конечно вряд ли данный реквизит существенно влияет на производительность, но определенные неудобства может создавать когда сбивается нумерация (как правило 1с контролирует уникальность данного реквизита). Непонятно зачем в ТК при нумерации кодов в справочниках и номеров в документах к числу добавляются нули, например 000245. Это приводит к определенным проблемам при штрих-кодировании, когда появляются разные номенклатуры с кодами различающимися только ведущими нулями, ведь при печати штрих-кода нули удаляются, а при сканировании соответственно уже невозможно правильно идентифицировать номенклатуру отличающуюся только количеством ведущих нулей.

Вы никогда не пробовали синхронизировать базы? Обмениваться с другими базами? Вы никогда не пробовали длину кода в 0 символов выставлять? Какое отношение код имеет к штрихкодированию вообще?

Бредятина какая-то...

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

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

Бредятина какая-то....

(27) Вообще-то я про оптимизацию движка мс скля. Он не оптимизирован вообще. Причины, кстати, такие же как и у 1С-ки

> Сомнительно использование механизма характеристик для торговой и прочей деятельности. Смысл характеристики в том, что в поле документа или регистра остатков хранится не ссылка на справочник например размеров одежды или цветов одежды или страны-производителя и пр., а ссылка на запись другой таблицы (назовем ее ТаблицаХарактеристика), к которой подчинены несколько записей другой вспомогательной таблицы, где и хранятся типы и значения разных атрибутов – размеры, цвета, страны-производители, веса, габариты, по сути что угодно. В этой вспомогательной таблице есть поле «Вид свойства» (ссылка на справочник свойств, значения данного справочника – цвет, размер, страна и т.п., их можно сколько угодно создавать) и поле «Значение свойства» (например красный, синий, зеленый для цветов; 40, 41, 42 – для размеров и т.п.). Но для того чтобы хранить данные например о двух цветах и трех размерах нужно завести все возможные комбинации используемых цветов и размеров. Например Белый 42 размер, Белый 43 размер, Белый 44 размер, Синий 42 размер, Синий 43 размер, Синий 44 размер. Т.е. вводится большее количество записей в таблицы, чем есть в реальности – на два цвета и три размера (итого 5 записей) вводится 6 записей! Для трех цветов соотношение будет уже 6 к 9. По-видимому данный механизм 1С придумала для того, чтобы пользователь при отсутствии программиста мог сам добавлять произвольные характеристики (например товаров) используемые в данной организации или для того чтобы не вносить изменения в конфигурации из-за дополнительных свойств. Но во-первых обычный пользователь вряд ли сможет самостоятельно заполнить характеристики (скорее всего он про них и не знает), а во-вторых если приглашается программист, то ему по сути проще и правильнее добавить несколько колонок (в нашем примере цвет, размер) в несколько таблиц (приход, расход, остатки) и прописать их в движениях, чем использовать характеристики, а потом доделывать отчеты чтобы характеристики показывались в удобной форме и в-третьих программисты 1с уже есть во всех городах страны, возможно уже в деревнях есть, так что нет никакой проблемы вызвать программиста и доработать конфигурацию. И самое главное, очевидно характеристики ведут к проблемам с производительностью, удобством выбора значений (автопоиск значения по первым введенным символам не работает), а также усложнению конфигураций, т.к. приходится дорабатывать отчеты и различные модули под характеристики. Характеристики можно рассматривать как пример антипаттерна из классических трудов по программированию, где рассматривается ошибочное решение и к каким проблемам данное решение приводит. В данном случае возникающие проблемы – существенны, а заявленные плюсы – сомнительны. Регистр расчетов – вообще непонятно зачем нужен. А перерасчеты не всегда нужны, нужно выдавать лишь предупреждение о пересечении исключающих видов расчетов, зачастую нужно отменить невыход или другое событие, а не делать его перерасчет.

Откройте для себя отношения многие-ко-многим перед тем как писать всякую охинею.

Бредятина какая-то...

Все, дальше не хочу даже писать. Забаньте обратно этого гения-недоучку!

(15) Знаешь, а я видел достаточно поделок вот таких вот оптимизаторов. Это натуральные поделки, на которых невозможно что-то нормально вести и поддержка ооочень дорогая, потому что специфичная и ооочень долгая

(0) а как ты увидел, что не соблюдаются ? Чем посмотрел схему связей таблиц БД ? Или это касается конкретно хранения данных в какой-нибудь СУБД ? Тогда это вопрос к конкретной реализации, а не в целом "В 1с не соблюдаются правила нормализации баз данных "

(33) Ты о чем? Оптимизаторы уверены, что 1С работает только на МС СКЛ

(34) кто такие оптимизаторы?

Системные интеграторы на оракле прекрасно внедряют, и работает оно лучше чем на мс скл

Вы не знакомы со структурой классификаторов адресов ФНС?  - а при чем здесь классификатор ФНС? Речь о таблице в которой хранятся адреса в 1с. Она неоптимальна. А классификатор ФНС нужен лишь для загрузки данных, не более. Или вы думаете что так в классификаторе нужно также хранить и в 1с?

(34) v8: Получить структуру SQL-таблиц базы данных

(33) речь об организации данных именно в 1с.

(26) я не понимаю зачем использовать Гуид, если хватает для большинства задач числового ID. Скорее всего это ведет к снижению быстродействия

полный текст статьи здесь http://realprog.livejournal.com/665.html

(37) Млин, Вы думаете адреса в 1С сферические в вакууме и не имеют никакой связи с внешним миром? Для загрузки говорите только? Вы хоть раз в жизни видели формат отчетности для налоговой?

(40) К какому снижению? С чего она должна снижаться?

(40) какого числового ID? какая разница какого он типа, главное что уникален, и его уникальных состояний хватит до конца твоей жизни

по большому счету это и есть число. 16-ричное.

(39) а при чем тут нормализация в объектной среде ? Чем тебе не нравится у реквизита тип ссылка на какой-то объект.
Это как-раз и есть нормализация в полном смысле. Хотя, какое может быть тут сравнение объектного подхода и реляционного способа хранения данных

(42) Отчетность? Налоговая? Что это такое? Первый раз слышу вообще.
Давайте говорить конкретными примерами, а не обрывками. Что с отчетностью конкретно не так?

(13) ты какой-то странный...

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

по существу в 1с есть обьекты разного уровня, от простых таблиц (не переодический РС) до навороченых на платформеном уровне мультитабличных обьектов.

НИ КТО НЕ МЕШАЕТ ВЕСЬ УЧЕТ СДЕЛАТЬ НА ПРОСТЫХ ТАБЛИЦАХ! хочешь - делай!

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

Вообще такого фееричного бреда я не слышал давно (как с мисты ушел один известный товарищь).

Да у 1с есть определенные проблеммы с индексами, есть ограничения маштабируемости (длинна кластерного индекса), есть отдельные узкие места в конкретных реализациях.
Но в целом 1с очень прогрессивна, надежна и даже быстра по сравнению с остальными БЕК системами. Разумеется если сравнивать с фронт системами 1с проиграет, но она для другого.

Вообще не вижу смысла спорить и доказывать что теплое действительно теплое.

(46) я такого нигде не писал, меня абсолютно устраивают ссылочные типы. Ты не понял о чем речь вообще

(40) число может быть уникально только в пределах ОДНОЙ таблицы. Гуиды уникальны в мировом масштабе, по этому по гуиду можно определить например элемент создан в этой базе или он перенесен из другой

(48)  использовать обычные регистры и откразаться от бухглатерских счетов предлагаешь? в этом ты видишь выход? а может лучше изменить систему хранения итогов?

(50) для распределенных баз есть, по крайней мере в 77 было - инф. база создания, поле.
мне не нужен гуид в мировом масштабе.
кстати думаю это существенно все замедляет. одно дело числовой id другое дело 16-ричный гуид строковый

(51) предложи КОНКРЕТНУЮ систему хранения итогов

(52) "думаю это существенно все замедляет"
Замеры в студию. Иначе - просто мистабольство.

(53) да давно уже кто-то писал на форумах что нужно хранить на обычных регистрах. Уже писали раньше это

(51) >> а может лучше изменить систему хранения итогов?
Зачем? Может попробовать абстрагироваться от того, как 1Сина хранит данные в СУБД?

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

(52) почитай http://www.sql.ru/articles/mssql/03013101indexes.shtml

и потом скажи на каком этапе число быстрее гуида?

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

(58) ты меня отсылаешь к технической статье листов на 10-20. Там читать не один час, а может и день. Если есть что конкретно сказать - говори. Нет, отсылки на википедию или тома страуструпа не катят. Говори конкретно.

(47) Я и вижу, что Вы все в первый раз видите. НДФЛ-2 в налоговую никогда не сдавали?

(60) Маня, ты матчасть не знаешь, а пытаешься что-то критиковать. Это называется пуканьем в лужу.

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

(50) что?) с какого бодуна он уникален в мировом масштабе? Гуиды винды уникальны, гуиды 1с - искуственны, простой инкремент значения, и уникален он только в пределах одной таблицы

(61) говори конкретно что не так с отченостью и адресами

(62) не знал что в лужу можно пукнуть

(60)
1. индексированое число и индексированый гуид по скорости РАВНЫ
2. 1с использует составной кластерный индекс (он ограничен длинной), и для него требуется не только индекс, но и описатель типа, по этому в составном индексе любые приметивные типы (в том числе и число) занимает БОЛЬШЕ места чем ссылка (гуид), по этому 1с и заточена на длинные гуиды которые уникальны не в пределах одной таблицы а в пределах мира и по этому при составления индекса к ссылке не нужно ничего добавлять

(52) Хорошо. Давайте так.
Гуид. Тип binary 16. Размер 16 байт (и нифига не строковый к слову).
Какое число предлагается? Тип (соответсвенно размер его в скуле, например).

(65) Конкретно там адрес в формате ФНС. Который в свою очередь из КЛАДР. Который по Вашему мнению "только для загрузки".

Санкт-Петербург - это город в Вашей стройной классификации? Или что?

(67) по скорости РАВНЫ - Равны в чем? В скорости создания индекса? Сомневаюсь

(70) скорость создания и записи никого не волнует, волнует скорость поиска и чтения

(64) Если не лезть шаловливыми ручками, то вероятность совпадения гуидов в разных базах настолько ничтожна, что ею вполне можно пренебречь.
Уникальность действительно отслеживается внутри 1 таблицы. Но еще раз - не критично, если не присваивать его руками

(63) а опять, же, при чем тут 1С в целом. Делай как лучше, а примеры - это и есть примеры

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

(71) опачки... вот это заявка.

(75) для ЛЮБЫХ бек систем оптимизация скорости на чтение,
для фронт систем на запись

ты этого не знал???

если нет - о чем вообще разговор?

(73)+ не забыли, что в (0) "В 1с не соблюдаются правила нормализации баз данных "

(75) ну он тоже частенько в лужу...
:))

(71) Я бы так сформулировал. На тех объемах, на которых используется 1с, и дл этих задач - скорость чтения и поиска более критична скорости записи.
На 1с обычно не делают билинговые системы с сотнями миллионов записей в день. А на меньших объемах разница в скорости не сыграет.

(72) да понятно, просто зачем так категирично заявлять про уникальность в мировом масштабе, зная что это не так, а уважаемый vde69 прекрасно это знает.
З.ы. кстати недавно был свидетелем, база РИБ на 15 узлов, создались 2 документа одного вида с одинаковым Гуидом, не в одно время конечно, а с разницей в месяцок. Потом вот наблюдал прикольные пляски этого дока при обменах

(68) допустим bigint - 8 байт

из последний сообщений можно сделать вывод что в 1с нет проблем с производительностю. а они, на самом деле. Сайт Гилева, Му-му тому пример.
Кстати, а чего они молчат-то?

Подполковник ПВО больше шарит в структурах БД, чем типа РеальныйПрограммист. Чему щас в универах только учат? :)

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

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

(82) а что и где они должны говорить?

Я по крайней мере знаю альтернативные реализации регистра сведений и иерархических справочников

(82) Они есть. Но заменой гуида на bigint их не решить.

Кстати, при обмене сдругими системами в обязательном порядке придется передавать тип. Сейчас достаточной гуида.

(82) Гилев и Му-Му как раз своими примерами и показывают, что таки 1С может работать быстро. :)

(85) на форуме. Миста.ру

(88) они доказали что 1с может работать БЫСТРЕЕ. А понятие быстро - относительное

(82) в ПЛАТФОРМЕ - нет проблемм с производительностью
проблеммы есть с конкретными реализациями конфигурацию, которые возникают на 99.99999% из-за кривых ручек а не из-за платформы.

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

(86) А регистр сведений разве не просто плоская таблица? Как его еще можно реализовать?

По моему автор сильныйи качественный  троль, он настолько толсто троллит, что становится тонко.

(89) ну им наверное некогда болтовнёй заниматься. а мы так поучавствуем.

(94) я думаю что Гилев и МУ-му сейчас читают эту ветку. Но сказать что-то боятся. Имидж подпортить. То ли свой, то ли 1с

(40)SQL это майкрософт, майкрософт использует guid в сових базах  RealProg ты думаешь ты умней разработчиков майкрософт?

(96) что значит микрософт использует гуиды? Что заложена такая возможность в мс скл?

(95) Жги есче!!! Свой то имидж ты уже испортил и зачем-то вспомнил в суе великих.

(95) да кому она нужна твоя ветка, кроме местных бездельников.

(98) да нет, я серьезно предлагаю им высказаться. У них безусловное есть опыт и авторитет в данной области. Было бы интересно узнать их мнение

(97) в мс скл есть такой тип даже. Правда 1с его не использует, а использует бинари16 для его хранения.

(97) Да, конечно.
http://msdn.microsoft.com/ru-ru/library/ms190215(v=sql.105).aspx

(97) в sql есть тип данных uniqueidentifier
http://msdn.microsoft.com/ru-ru/library/ms187942.aspx

(102) я не против типа ГУИД. я против использования его в качестве ID в 1с. это излишне

(104) про индексы слышал? как они строятся для строки для числа и как для гуида? сколько занимает места индекс для каждого типа?

(104) В тех случаях когда требуется глобальная уникальность ключа - используется GUID. Для обменов между базами как раз нужна глобальная уникальность ключей.

(92) а вот так, что хранить период окончания (вычислять и хранить)
я именно про периодический имел ввиду
уменьшает скорость записи, но ускоряет чтение при "срезе последних на каждую дату"

(106)+ самый правильный ответ!! строка и число не могут быть уникальными в разных базах

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

(91) "в ПЛАТФОРМЕ - нет проблемм с производительностью"
да ты просто ортодоксальный адинесник. :)
помню недавно флудили на тему идиотского интерпритатора, который выполняет код быстрее, если он написан в одну строку.
я думаю в 1с таких моментов придостаточно. в т.ч. и при работе с БД.

А нах 1С таскает с сервера БД данные чтобы на основе них сделать запись, если все это можно было сделать непосредственно в СУБД без таскания по сети данных

(100) Ты слишком толстый=)

(111) чего куда таскает?

(109)
>>>я уже ответил про индексы
не отвечал, ты игнорируешь вопросы (стиль Самосвала)

>>>найти индек гуидовский тоже больше времени
ты упорно врешь, не смотря на то что я тебе приводил и документацию по индексам и описывал упрощенно

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

(100) в области чего, конкретней? Будут конкретные вопросы?

(113) на пальцах:
проводим документ, что делает платформа:
1. пишет данные документа в БД
2. опять из БД тащим только что записанные данные документа обратно, а это ТЧ на кучу строк
3. на основе них снова в БД записываем в регистр данные

(111) тонкий клиент уже не таскает, если ты про это

(111) по тому что 1с работает не только на скуле, и не факт что фишка поддерживается субд, и кроме того если используется кластер серверов то требуется серверный кеш для обеспечения уникальности

А еще в 1с есть разница между пустая ссылка, неопределено и Null :)))

(115) в области темы описанной в статье. Ты не догадался?

(119) :))) в чем она, если не секрет?

(109) разница между bigint и гуидом 8 байт. Имхо, выигрыш будет максимум процентов 10 от размера базы. Причем скорее даже 5

(117) да? прямо в триггерах пишет?
(118) гнилые отмазы ))

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

(119) этот вопрос должен задавать только я

(125) иностранный агент?

(126) ты меня плохо знаешь

(123) по сети все данные не гоняет, только картинку. Остальное все на сервере остается

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

(120) не догадываюсь. "В 1с не соблюдаются правила нормализации баз данных как на уровне системных таблиц платформы, так и на уровне таблиц типовых конфигураций."
Огласите список, пжлста...
Каких таблиц ?

(128) ты даже не понял про что я, я про данные между сервером приложений и СУБД

(124) По моему опыту наиболее существенная деградация производительности происходит не из-за размера соединяемых поле, а из-за неэффектиных планов запросов. Когда вместо нормального поиска по индексу все сваливается в table scan.
А это проблема не плаформы, а конкретной реализации (конфигурации)

(130) удалили из ветки полный текст. Здесь он http://realprog.livejournal.com/665.html

(130) что это за "системные таблицы" такие у платформы (у платформы!), и это - "таблиц типовых конфигураций" ?

(133) надо (25) читать было. Не надо выкладывать такие простыни на форум, дай небольшие выдержки по смыслу, и ссылку.

(134) ты ветку читаешь? сейчас обсуждаем таблицы бухгалтерских итогов.

(133) в твоем бложике явно перепутаны понятия "просто" и "примитивно",  все зависит от IQ человека, кому то сложно врубаться в тему а кому то нет. чем ниже IQ тем приметивнее решение чем выше тем красивее. красиво - значит просто!!
примитивно - значит тебе еще учиться надо!

(82) Потому что проблемы лежат совершенно в другой плоскости.

(83) Раньше замполитов учили лучше, чем сейчас программистов :)

(136) ну так и надо было ветку начинать, типа
"Насколько устраивает вас такой вариант бухитогов, при котором все данные хранятся в одной табл"
Это конкретно.
А то, блин, на весь 1С шум поднял
На святые понятия руку поднял "Нормализация" и 1С

(139) ну почему, проблемы с нормализацией есть например в таблицах адресов. Проблемы описаны в ссылке. Почитай

(139) хотя нет. я забыл там кое-что написать. ладно. не важно

(140) Ептыть! Вы не пробиваемый! Нет там такой проблемы. Там оптимальная реализация задачи исходя их неформализованной структуры адреса в реальной жизни.

Предложите свою структуру хранения, если Вы такой умный. С удовольствием посмотрю на нее.

(140) Про адреса тебе уже ответили. Ноги растут не из 1С, а из КЛАДРа.

(0) Ваня, ты б с пивом завязывал таки :)))))))

(144) не может пиво так влиять на умственное состояние. Это минимум тяжёлые наркотики.

+ (143) Это насчет ссылок на элементы адреса. При первом же обновлении КЛАДР часть адресной информации у тебя превратится в кашу.
Хранение всей контактной информации в одной таблице - принято практически во всех CRM и подобных системах (даже в почтовых клиентах).
Ты хочешь сказать что все вокруг ошибаются, и ты с первого взгляда понимаешь что делать нужно иначе?

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

Совсем забыл - отчеты по проводкам, отчеты по субконто (карточка/анализ)

(0) мдя, ты еще не знаешь видимо, что  базу любой сложности можно описать в 4 физических таблицах, вот он предел нормализации

(150) В одной. Есть простое доказательство что достаточно одной таблицы. А вообще по большему счету достаточно одномерного массива.

(150) ты хотел сказать денормализации?

(0) Отвечаю по порядку.

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

Существует несколько нормальных форм (от 1 до 6). На практике люди часто ограничиваются 3-ей. Выбор уровня нормализации определяется разработчиком на основе многих факторов: требований к скорости записи, к скорости чтения, к ссылочной целостности.

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

В платформе 1С на уровне системных таблиц соблюдается 3-я нормальная форма, требования которой звучат так: каждый неключевой атрибут неприводимо (функционально полно) зависит от ее потенциального ключа.

___________
>> Требования нормализации не соблюдаются в критически важных таблицах 1с – бухгалтерских итогов, проводок.

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

Регистры бухгалтерии рекомендуются к использованию для построения богатой системы учёта в целях ведения неоперативного учёта и получения разнообразной управленческой отчётности.

___________
>> Бухгалтерские итоги по всем счетам хранятся в одной таблице, без разбиения на разные таблицы в зависимости от типа аналитики счета, а ведь разные счета хранят разные по структуре данные! Например на счетах взаиморасчетов (60, 62, 76 бух. счета) хранится информация по следующим измерениям (субконто): контрагенты, договора, документы. А на счетах учета материалов (10 счет) – по номенклатуре и складам.

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

___________
>> Как следствие в таблицу итогов кроме полей «субконто», вводятся поля «тип субконто» (??? А может и не вводятся, а если и вводятся только для неопределенных полей. Нужно проверять таблицы в MS SQL, в 8 версии вроде переделали).

Очевидно, автор не обладает точной информацией. Предлагаю проверить.

>> Соответственно к индексам введенным для субконто, вводятся еще индексы для полей «тип субконто». В случае плана счетов с максимальным количеством субконто к счету равным 3, количество индексов в таблице бух. итогов вместо 4 (3 для трех субконто и 1 для счета) становится 7 (дополнительно еще 3 для типа субконто). Это может существенно влиять на производительность, с учетом того что все документы формирующие бух. проводки будут формировать записи в данной таблице.

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

___________
>> Также существенным минусом является то, что количество полей-субконто одинаково для всех счетов, ведь как уже было сказано остатки по всем счетам хранятся в одной таблице. Считается нежелательным добавлять больше 3 субконто к счету, а в 7.7 вообще невозможно было больше 5 создать, это было ограничение платформы.

Очень сложно себе представить Планы счетов с 6 и более субконто, поэтому 5 уровней аналитики вполне достаточны для построения очень замудрённой схемы учёта. Кстати, есть ещё измерения регистра бухгалтерии, которые тоже можно считать доп.аналитикой. Если же нужна ещё более детальная аналитика, то всегда можно завести регистр накопления.

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

Можно добавить реквизиты регистра бухгалтерии. Это не приведёт к раздуванию таблицы итогов.

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

Зато можно наложить RLS на План счетов, в том числе на конкретные счета. Эти ограничения будут действовать при выборе итогов из таблицы регистра.

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

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

___________
>> - Сомнительно использование механизма характеристик для торговой и прочей деятельности.

Механизм характеристик гениально просто и удобен. Сомнительно было создавать в платформе доп.объект типа "План видов характеристик" вместо "Справочник", но раз уж создали, пусть будет. Зато теперь программисты могут создавать решения, которые ПОЛЬЗОВАТЕЛЬ сможет настраивать на свой вид деятельности (создавать свои свойства и наборы свойств, завязывать логику отчётов и других алгоритмов на эти свойства).  

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

Смысл механизма характеристик немного не в этом. Это всего лишь частный случай. Смысл в создании свойств объектов на этапе использования решения, а не на этапе программирования, т.е. в режиме 1С:Предприятие, а не в режиме "Конфигуратор". После того, как свойство создано, можно заполнять его данными, а дальше учитывать эти значения при обработке этих объектов.

Кстати, названная таблица обычно является регистром сведений "ЗначенияСвойствОбъектов" или аналогичным с измерениями Объект, Свойство и ресурсом Значение. Если свойство допускает множественное значение, то можно добавить ещё измерение "номер".

___________
>> В этой вспомогательной таблице есть поле «Вид свойства» (ссылка на справочник свойств, значения данного справочника – цвет, размер, страна и т.п., их можно сколько угодно создавать) и поле «Значение свойства» (например красный, синий, зеленый для цветов; 40, 41, 42 – для размеров и т.п.).

Там есть ещё поле "Объект" и оно ключевое, главное.

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

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

___________
>> Например Белый 42 размер, Белый 43 размер, Белый 44 размер, Синий 42 размер, Синий 43 размер, Синий 44 размер. Т.е. вводится большее количество записей в таблицы, чем есть в реальности – на два цвета и три размера (итого 5 записей) вводится 6 записей! Для трех цветов соотношение будет уже 6 к 9.

Не нужно их вводить.

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

Да, точно! Именно для этого.

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

Конечно, этот механизм предназначен для ПРОДВИНУТЫХ пользователей, которые многое умеют сами.

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

Менять типовые конфигурации вообще не рекомендуется. Слетаешь с поддержки.
Грамотные программисты стараются не менять без необходимости типовые конфигурации или менять минимально, а грамотные пользователи, консультанты, владельцы бизнесов стараются использовать существующие отлаженные решения, а не разрабатывать новые.

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

Проблема в деньгах. Программисты 1С очень дорого стоят, особенно грамотные.
Другая проблема в квалификации программистов и сложности конфигураций.
И ещё есть проблема в других странах, там мало 1С-программистов, а платформа 1С уже используется.

___________
>> И самое главное, очевидно характеристики ведут к проблемам с производительностью,

Это решаемые проблемы. И не всегда они главные. Характеристики нужны для свободы, а не для скорости.

___________
>> удобством выбора значений (автопоиск значения по первым введенным символам не работает)

В чём проблема починить?

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

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

Например, СКД позволяет прикрутить этот механизм парой кликов мышки. Надо всего лишь указать План видов характеристик, регистр свойств и справочник доп.значений. Остальное сделает платформа.

___________
>> Характеристики можно  рассматривать как пример антипаттерна из классических трудов по программированию,

Классическая парадигма программирования менялась со временем, причём новые парадигмы отрицали старые, были антипаттернами для них в некоторых отношениях.

___________
>> где рассматривается ошибочное решение и к каким проблемам данное решение приводит. В данном случае возникающие проблемы – существенны, а заявленные плюсы – сомнительны.

Жизнь доказала необходимость и полезность решения. Возможно, оно не идеально с точки зрения нормализации таблиц и производительности, но оно работает.

___________
>> Регистр расчетов – вообще непонятно зачем нужен.

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

___________
>> А перерасчеты не всегда нужны, нужно выдавать лишь предупреждение о пересечении исключающих видов расчетов, зачастую нужно отменить невыход или другое событие, а не делать его перерасчет.

Перерасчёты нужны для учёта взаимозависимостей записей расчётов. Например, НДФЛ зависит от полученного дохода, который зависит от оклада и отработанных дней. При изменении рассчитанной зарплаты по окладу должен пересчитаться налог. Для этого и нужны перерасчёты.

___________
>> - Ошибки есть не только на уровне платформы, множество сомнительных решений допускается при проектировании типовых конфигураций.

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

___________
>> Например таблица адресов – поля нессылочные, просто записывают текст "г. Москва", вместо ссылки на справочник городов. То же самое с областями, улицами. Очевидно это нарушение принципа реляционности.

Работа с адресами сложна сама по себе. Дело в том, что есть такой КЛАДР (Классификатор адресов России) и типовые конфигурации стараются использовать его. Этот КЛАДР постоянно меняется, потому что мы не живём в стране с зафиксированными городами и улицами. Строятся дома, города расширяются, улицы переименовываются… Вот недавно Москву расширили в 2.5 раза.

Отсюда делаем вывод, что соблюдение даже 3-й нормальной формы будет неверным решением и вполне достаточна 2-я нормальная форма.

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

Честно говоря, не очень понял, чем отличается принципа реляционности от принципа нормализации.

___________
>> Ссылочный тип дал бы возможность простого анализа продаж по типам регионов, городов и т.д.

Но он бы привёл к проблеме обновления КЛАДРа и синхронизации введённых данных с новым классификатором.

___________
>> Но и это еще не все. В таблице адресов хранятся не только адреса, но и телефоны, e-mail, по сути там мешанина данных как и в таблице бухгалтерских остатков.

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

___________
>> Аналогичные проблемы с адресами физлиц, т.к. они хранятся в той же таблице что и адреса контрагентов.

Отфильтровать их друг от друга не проблема:
ВЫБРАТЬ * ИЗ РегистрСведений.КонтактнаяИнформация
ГДЕ Объект ССЫЛКА Справочник.ФизическиеЛица

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

К разработке этого модуля привела жизнь и более 20 лет опыта автоматизации на платформе 1С.

___________
>> При этом рекомендую всем посмотреть данный модуль для работы с адресами. Сложность его не соответствует решаемой задаче (см. пункт 1).

Поверь, задача хранения контактов и адресов реально сложная. Очень много затыков идёт именно на этом.

Кстати, даже бухгалтерскую отчётность не сдать, если юр.адрес организации не соответствует определённому шаблону, чего уж говорить об отчётности в ПФР по физлицам. А задачи автоматизации CRM требуют богатого применения различных контактов, поскольку на них часто держатся продажи и сам бизнес.

___________
>> Можно конечно попробовать возразить, что соединения таблиц может быть ресурсоемким в случае больших таблиц и поэтому хранится не ссылка, а текст "г. Москва", но в данном случае скорее всего данные таблицы не настолько велики.

Они достаточно велики. Тысячи контрагентов, клиентов, физлиц, контактных лиц и по каждому нужно хранить 3-4 контакта и пару адресов.

___________
>> Также нужна история адресов, ведь адреса могут меняться.

Тогда регистр сведений надо сделать периодическим.

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

Очень спорное. По одному договору может проходить несколько контрагентов.

___________
>> - Во все справочники ТК добавлен автоматически нумеруемый реквизит «Код» (причем не всегда уникальный),

Если в конфигураторе задать длину кода = 0, то такого поля не будет. Это настраивается программистом.

___________
>> при создании нового справочника в конфигураторе также по умолчанию создается данный реквизит. Хотя для большинства справочников он не нужен.

Код нужен для идентификации элементов и возможности их безопасного переименования.

___________
>> Он может понадобиться разве что для справочника Основных средств, Номенклатуры, да и то только под названием «Инвентарный номер», а также справочника «Сотрудники» под названием «Табельный номер».

В чём проблема завести соответствующие реквизиты? или действительно задействовать поле "Код" для хранения инвентарных и табельных номеров?

___________
>> Интересно, какой процент программистов 1с задумывался над данным вопросом?

Интересно, почему автору интересен процент таких программистов? :)

___________
>> Конечно вряд ли данный реквизит существенно влияет на производительность, но определенные неудобства может создавать когда сбивается нумерация (как правило 1с контролирует уникальность данного реквизита).

Контроль уникальности настраивается, но нумерация иногда действительно сбивается по вине платформы. Это печально, но есть метод ОбновитьнумерациюОбъектов().

___________
>> Непонятно зачем в ТК при нумерации кодов в справочниках и номеров в документах к числу добавляются нули, например 000245.

Для использования префиксов в номерах строкового типа, например, АБВ0001 или 13-0001. Количество нулей позволяет понять длину номера и количество резервных старших разрядов, которые можно задействовать. Без этих нулей автоматическая нумерация возможна только для кодов типа "число".

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

Это чисто конкретная проблема, которую надо решить на организационном уровне.

___________
>> - В качестве ключевого поля (уникального идентификатора) для таблиц используется поле типа GUID, хотя в 7.7 версии хватало поля числового типа.

Если мне не изменяет память, в версии это поле было не числовое, а строковое. В v8 пошли ещё дальше и сделали его гарантированно уникальным, что прекрасно. Общее количество уникальных GUID настолько велико (2^128 или 3,4028x10^38), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала.

___________
>> Очевидно в большинстве случаев хватит числового идентификатора. Вероятно использование GUID отрицательно влияет на быстродействие соединения таблиц в запросах, на создание, запись и проведение справочников, документов.

Чем-то приходится жертвовать. Для скорости можно использовать регистры сведений, в которых нет GUID.

___________
>> С данным полем достаточно неудобно работать в 1с.

Из 1С с ним и не надо работать. Платформа автоматически поддерживает разыменование сссылочных полей (обращение через точку), в том числе в запросах.

___________
>> К тому же вряд ли получится использовать GUID-поле для штрих-кодирования например номенклатуры или основных средств.

Никто не заставляет. Лучше завести поле "Штрих-код" или использовать регистр «Штрих-коды».

___________
>> Полагаю это достаточно редкое решение при построении баз данных – использовать GUID-поле в качестве ключевого поля.

Это решение работает. Дёшево, надёжно и практично.

================================================

Мой общий вывод об этом "пасквиле на 1С" такой.

Автор плохо разбирается в платформе и её механизмах. Этой статьёй он пытался очернить платформу, которая работает, приносит пользу бизнесу и кормит армию голодных программистов, бухгалтеров, а также их семьи. Зачем?

Но вероятно, не всё ещё потеряно. Например, он даже согласился заплатить мне 1500 руб за критику его критики. Т.е. он реально зантересован разобраться или это был такой маркетинговый ход для продолжения огульной критики платформы 1С? :)

(152) в данном случае нормализации, гуглить "Универсальные модели данных"

(153) Ответ внушает :)

(153) МОЩНО!!!!!!!!!!!!!!!!!
Внушаить!!!!
Респект!!!

(15) Мы тебя слышим, товарищ!

(153) и не лень было троллю отвечать...

2(153) А можно завести РБ совсем без субконто, но с 10 измерениями... и будет практически тот же РН, но только с поддержкой корреспонденций.

(153) респект!

(158) мне кажется здесь дело не в то троль или нет, мотивация несколько иная.

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

(157) Не похоже

(161) Деньги гоните...

Если он деньги зажмет, то значит адинесник.

(153) Шикарно. Но наверное не стоило.

(163) Он уже заплатил

Маня выступи на инфостарт эвенте с критикой. Вот это будет тема.

(167) выступит? выступил? выступил бы, но не судьба?

ответ на ответ Волшебника. На то что посчитал важным. Каждый кто прочтет сделает выводы сам.
--------------------------------------

>> Соответственно к индексам введенным для субконто, вводятся еще индексы для полей «тип субконто». В случае плана счетов с максимальным количеством субконто к счету равным 3, количество индексов в таблице бух. итогов вместо 4 (3 для трех субконто и 1 для счета) становится 7 (дополнительно еще 3 для типа субконто). Это может существенно влиять на производительность, с учетом того что все документы формирующие бух. проводки будут формировать записи в данной таблице.

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

RealProg:  ты не понял, я не против индекса, я против добавления типа субконто в таблицу, которое влечет также и создание индекса.
___________
>> Кроме того, по сути невозможно добавить поля в таблицу движений конкретного счета (она ведь одна на все счета).

Можно добавить реквизиты регистра бухгалтерии. Это не приведёт к раздуванию таблицы итогов.

RealProg:  ну как же не приведет? Там каждое новое измерение после трех уже чувствительно.
___________
>> Также невозможно сделать RLS (ограничение доступа к данным на уровне конкретных записей а не всей таблицы) по бухгалтерским остаткам и движениям.

Зато можно наложить RLS на План счетов, в том числе на конкретные счета. Эти ограничения будут действовать при выборе итогов из таблицы регистра.

RealProg:  Чем это поможет в случае 70 бухсчета, когда нужно ограничить видимость по сотрудникам?

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

В общем случае, не нужно. Но если нужно хранить данные об остатках этих характеристик, например, остатки определённых артикулов заданных цветов, то, можно, хотя необязательно.
RealProg:  ничего не понял. Как это не обязательно? Если нужно хранить, значит нужно и заводить.
___________
>> Например Белый 42 размер, Белый 43 размер, Белый 44 размер, Синий 42 размер, Синий 43 размер, Синий 44 размер. Т.е. вводится большее количество записей в таблицы, чем есть в реальности – на два цвета и три размера (итого 5 записей) вводится 6 записей! Для трех цветов соотношение будет уже 6 к 9.

Не нужно их вводить.
RealProg:   почему не нужно?
___________
>> и в-третьих программисты 1с уже есть во всех городах страны, возможно уже в деревнях есть, так что нет никакой проблемы вызвать программиста и доработать конфигурацию.

Проблема в деньгах. Программисты 1С очень дорого стоят, особенно грамотные.
Другая проблема в квалификации программистов и сложности конфигураций.
И ещё есть проблема в других странах, там мало 1С-программистов, а платформа 1С уже используется.
RealProg:  по-моему из-за характеристик стоимость доработок только возрастает

___________
>> удобством выбора значений (автопоиск значения по первым введенным символам не работает)

В чём проблема починить?
RealProg:  ты не починишь. Как ты сделаешь автовыбор характеристики «Синий 44 размер»? В случае двух отдельных полей можно было бы ввести «си» и «44» в двух полях. В случае одного поля-характеристики так не получится.
___________
>> Регистр расчетов – вообще непонятно зачем нужен.

Как резко сменилась тема разговора. Кстати, кому непонятно?
Регистры расчётов нужны для автоматизации учёта сложных периодических расчётов, обычно, зарплаты сотрудников.
RealProg:  согласен, не в тему написал. Хотя это не отменяет данного утверждения. На мисте кстати это обсуждали
___________
>> Например таблица адресов – поля нессылочные, просто записывают текст "г. Москва", вместо ссылки на справочник городов. То же самое с областями, улицами. Очевидно это нарушение принципа реляционности.

Работа с адресами сложна сама по себе. Дело в том, что есть такой КЛАДР (Классификатор адресов России) и типовые конфигурации стараются использовать его. Этот КЛАДР постоянно меняется, потому что мы не живём в стране с зафиксированными городами и улицами. Строятся дома, города расширяются, улицы переименовываются… Вот недавно Москву расширили в 2.5 раза.

Отсюда делаем вывод, что соблюдение даже 3-й нормальной формы будет неверным решением и вполне достаточна 2-я нормальная форма.

RealProg:  просто не согласен. Ну и что что КЛАДР меняется? Курсы валют тоже каждый день меняются, однако никаких проблем каждый день закачать новые

___________
>> Ссылочный тип дал бы возможность простого анализа продаж по типам регионов, городов и т.д.

Но он бы привёл к проблеме обновления КЛАДРа и синхронизации введённых данных с новым классификатором.

RealProg:  в чем проблема обновления кладр? Ведь его и так обновляют?
___________
>> Но и это еще не все. В таблице адресов хранятся не только адреса, но и телефоны, e-mail, по сути там мешанина данных как и в таблице бухгалтерских остатков.

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

RealProg:  чтобы проще было. И не будет ненужного общего модулая УправлениеКонтактнойИнформацией. И даже переопределяемого не будет, представляете?
___________

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

К разработке этого модуля привела жизнь и более 20 лет опыта автоматизации на платформе 1С.

RealProg:  не согласен
___________
>> При этом рекомендую всем посмотреть данный модуль для работы с адресами. Сложность его не соответствует решаемой задаче (см. пункт 1).

Поверь, задача хранения контактов и адресов реально сложная. Очень много затыков идёт именно на этом.

Кстати, даже бухгалтерскую отчётность не сдать, если юр.адрес организации не соответствует определённому шаблону, чего уж говорить об отчётности в ПФР по физлицам. А задачи автоматизации CRM требуют богатого применения различных контактов, поскольку на них часто держатся продажи и сам бизнес.

RealProg:  не согласен
___________
>> Также нужна история адресов, ведь адреса могут меняться.

Тогда регистр сведений надо сделать периодическим.

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

Очень спорное. По одному договору может проходить несколько контрагентов.

RealProg:  По одному договору не может проходить несколько контрагентов, т.к. договор подчинен контрагентам.
___________
>> - Во все справочники ТК добавлен автоматически нумеруемый реквизит «Код» (причем не всегда уникальный),

Если в конфигураторе задать длину кода = 0, то такого поля не будет. Это настраивается программистом.

RealProg:  поменять можно, но зачем в типовых по умолчанию вставляют код?
___________
>> при создании нового справочника в конфигураторе также по умолчанию создается данный реквизит. Хотя для большинства справочников он не нужен.

Код нужен для идентификации элементов и возможности их безопасного переименования.

RealProg:  для идентификации используется ID или ГУИД, тебе ли это не знать?
___________
>> Он может понадобиться разве что для справочника Основных средств, Номенклатуры, да и то только под названием «Инвентарный номер», а также справочника «Сотрудники» под названием «Табельный номер».

В чём проблема завести соответствующие реквизиты? или действительно задействовать поле "Код" для хранения инвентарных и табельных номеров?

RealProg:  спроси у разработчиков типовых

___________
>> Непонятно зачем в ТК при нумерации кодов в справочниках и номеров в документах к числу добавляются нули, например 000245.

Для использования префиксов в номерах строкового типа, например, АБВ0001 или 13-0001. Количество нулей позволяет понять длину номера и количество резервных старших разрядов, которые можно задействовать. Без этих нулей автоматическая нумерация возможна только для кодов типа "число".
RealProg:  код это числовой реквизит, нули не нужны

>> Полагаю это достаточно редкое решение при построении баз данных – использовать GUID-поле в качестве ключевого поля.

Это решение работает. Дёшево, надёжно и практично.
RealProg:  но при этом более медленно по всей видимости

================================================

Мой общий вывод об этом "пасквиле на 1С" такой.

Автор плохо разбирается в платформе и её механизмах. Этой статьёй он пытался очернить платформу, которая работает, приносит пользу бизнесу и кормит армию голодных программистов, бухгалтеров, а также их семьи. Зачем?

Но вероятно, не всё ещё потеряно. Например, он даже согласился заплатить мне 1500 руб за критику его критики. Т.е. он реально зантересован разобраться или это был такой маркетинговый ход для продолжения огульной критики платформы 1С? :)

RealProg:  очернить никого не пытался, тем более высшее руководство Партии. Всего лишь хочу чтобы наверху (показываю пальцем вертикально вверх) в Центральном Комитете услышали о некоторых критически важных проблемах, волнующих граждан Союза 1С.

http://www.sql.ru/forum/actualthread.aspx?bid=36&tid=1019530&pg=-1

(169) Вы не в теме совершенно. Не пишите эту безумную хрень. Только позоритесь...

Пускай пишет. Нечего такую хрень в себе держать.

(169) всё-таки внятно объясни нам, почему все программы, которых было море в 90-е годы, которые четко придерживались правил нормализации, и делали бухгалтерию на регистрах накопления, все оказались в заднице, хотя они и посмеивались над 1с, говорили, что за бред, какие-то субконты, гуиды. И где они теперь с их нормализацией? Выиграла 1с, которая предложила свое решение, и оно выдержало проверку временем.

(169)

>> RealProg:  ты не понял, я не против индекса, я против ..., которое влечет также и создание индекса.

Нарушение логики.

____
>> RealProg:  ну как же не приведет? Там каждое новое измерение после трех уже чувствительно.

реквизит, а не измерение

____
>> RealProg:  Чем это поможет в случае 70 бухсчета, когда нужно ограничить видимость по сотрудникам?

Проблема решаема.

____
>> RealProg:  ничего не понял. Как это не обязательно? Если нужно хранить, значит нужно и заводить.

В регистре остатков можно завести измерения типа "Характеристика".

___
>> RealProg:   почему не нужно?
можно без них

___
>> RealProg:  по-моему из-за характеристик стоимость доработок только возрастает

В целом удешевляется, потому что доработок требуется меньше.

___
>> RealProg:  ты не починишь. Как ты сделаешь автовыбор характеристики «Синий 44 размер»? В случае двух отдельных полей можно было бы ввести «си» и «44» в двух полях. В случае одного поля-характеристики так не получится.

Я сделаю.

___
>> RealProg:  согласен, не в тему написал. Хотя это не отменяет данного утверждения. На мисте кстати это обсуждали

без комментариев

___
>> RealProg:  просто не согласен. Ну и что что КЛАДР меняется? Курсы валют тоже каждый день меняются, однако никаких проблем каждый день закачать новые

Всё дело в ключевых атрибутах и принципах нормализации. Для КЛАДРа ключевыми атрибутами являются строки (названия символов), а не числа (их некие коды).

___
>> RealProg:  в чем проблема обновления кладр? Ведь его и так обновляют?

Его обновляют ежеквартально и это прекрасный пример расхождения реляционной модели с реальной жизнью. Эту тему можно развить очень глубоко, но я не рекомендую это делать. Иначе ты поймёшь, почему на практике используют 3-ю нормальную форму и даже иногда 2-ю.

___
>> RealProg:  чтобы проще было. И не будет ненужного общего модулая УправлениеКонтактнойИнформацией. И даже переопределяемого не будет, представляете?

Будет сложнее. Уж лучше НУЖНЫЙ модуль УправлениеКонтактнойИнформацией, чем тот балаган, который был до его изобретения.

___
>> RealProg:  не согласен
Это не вопрос соглашения. Предложи решение лучше.

___
>> RealProg:  не согласен
Поверь моему 20-летнему опыту.

___
>> RealProg:  По одному договору не может проходить несколько контрагентов, т.к. договор подчинен контрагентам.

Это в 1С подчинён, а в реальной жизни не подчинён.

___
RealProg:  поменять можно, но зачем в типовых по умолчанию вставляют код?

Вопрос явно не к мисте. Обратись к разработчику типовых.

___
>> RealProg:  для идентификации используется ID или ГУИД, тебе ли это не знать?

Для идентификации можно использовать и то, и другое. Смысл в идентификации, а не в выборе поля/алгоритма. Т.е. в каждом конкретном случае для идентификации используется своё поле. В некоторых случаях достаточно крикнуть "Вася!", а в других случаях нужна нотариально заверенная подпись или GUID по алгоритму RSA ("Боб-Алиса").

___
>> RealProg:  спроси у разработчиков типовых

спроси у разработчиков типовых

___
>> RealProg:  но при этом более медленно по всей видимости

Более медленнее чего? Чем могло бы? Чем другие решения?
Для этого фирма Intel выпускает новые процессоры, а фирма Microsoft выпускает новые ОС. Фирма 1С работает над платформой, обеспечивающей удобство разработки, высокую скорость разработки прикладных решений, а не скоростью работы прикладных решений.

Когда реально нужна скорость работы, платформа 1С может обеспечить требуемый функционал, но рекордов от неё не ждите. Не ждите высшего рейтинга в шахматных программах или в полнотекстовом поиске. Это другие задачи для других платформ. Платформа 1С решает СВОИ задачи, для которых предназначена, и с ПРИЕМЛЕМОЙ скоростью.

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

RealProg - это Маня?

Маня я думаю тебе бросаить уже пора программирование. зачем этой черной работой заниматься? Собирай команду и руководи.

Тема смешна, особенно учесть что маня не знает зачем нужна галка ведущее.

(178) Маня по сути больше внедренец чем программист. И его смысл мне понятен со всеми этими УФ и УТ 11 внедрения очень усложнились.

(179) Имхо УФ очень упростили как раз этап внедрения. УФ более  понятная технология.

думаю, это не Маня. Может его прог, но не уверен.

>> RealProg:  ты не понял, я не против индекса, я против ..., которое влечет также и создание индекса.

Нарушение логики.
RealProg: ты снова не понял, я против ненужного поля «тип субконто», которое к тому же влечет создание дополнительного ненужного индекса
____
>> RealProg:  ну как же не приведет? Там каждое новое измерение после трех уже чувствительно.

реквизит, а не измерение
RealProg: речь в обсуждении о бухитогах, реквизиты проводок тут не помогут. Проблемы с бухитогами, реквизитами в проводках их не решить

____
>> RealProg:  Чем это поможет в случае 70 бухсчета, когда нужно ограничить видимость по сотрудникам?

Проблема решаема.

RealProg: Как?
____
>> RealProg:  ничего не понял. Как это не обязательно? Если нужно хранить, значит нужно и заводить.

В регистре остатков можно завести измерения типа "Характеристика".
RealProg: но значения характеристик придется вводить

___
>> RealProg:   почему не нужно?
можно без них

RealProg: см. предыдущий пункт
___
>> RealProg:  по-моему из-за характеристик стоимость доработок только возрастает

В целом удешевляется, потому что доработок требуется меньше.

RealProg: больше. Куча приблуд была рождена для делания удобоваримым характеристики. Отчетов куча под них переделывалось. Только на компоновке более-менее приглядны отчеты стали
___
>> RealProg:  ты не починишь. Как ты сделаешь автовыбор характеристики «Синий 44 размер»? В случае двух отдельных полей можно было бы ввести «си» и «44» в двух полях. В случае одного поля-характеристики так не получится.

Я сделаю.
RealProg: стандартно этого нет. Я уже догадываюсь что это за извращение
>> RealProg:  просто не согласен. Ну и что что КЛАДР меняется? Курсы валют тоже каждый день меняются, однако никаких проблем каждый день закачать новые

Всё дело в ключевых атрибутах и принципах нормализации. Для КЛАДРа ключевыми атрибутами являются строки (названия символов), а не числа (их некие коды).

RealProg: но как-то же это с 1с синхронизируется?
___
>> RealProg:  в чем проблема обновления кладр? Ведь его и так обновляют?

Его обновляют ежеквартально и это прекрасный пример расхождения реляционной модели с реальной жизнью. Эту тему можно развить очень глубоко, но я не рекомендую это делать. Иначе ты поймёшь, почему на практике используют 3-ю нормальную форму и даже иногда 2-ю.

RealProg: 3-2 форма. Ты думаешь никто кроме тебя это не понимает?

___
>> RealProg:  не согласен
Это не вопрос соглашения. Предложи решение лучше.

RealProg: Тут и предлагать нечего. Делать то что есть в реальности.
___
>> RealProg:  не согласен
Поверь моему 20-летнему опыту.

RealProg: 20-летний опыт чего? 1с?
___
>> RealProg:  По одному договору не может проходить несколько контрагентов, т.к. договор подчинен контрагентам.

Это в 1С подчинён, а в реальной жизни не подчинён.

RealProg: подчинен
___
RealProg:  поменять можно, но зачем в типовых по умолчанию вставляют код?

Вопрос явно не к мисте. Обратись к разработчику типовых.

RealProg: именно это я и делаю через данный форум
___
>> RealProg:  для идентификации используется ID или ГУИД, тебе ли это не знать?

Для идентификации можно использовать и то, и другое. Смысл в идентификации, а не в выборе поля/алгоритма. Т.е. в каждом конкретном случае для идентификации используется своё поле. В некоторых случаях достаточно крикнуть "Вася!", а в других случаях нужна нотариально заверенная подпись или GUID по алгоритму RSA ("Боб-Алиса").

RealProg: в данном случае нужен четвертый вариант – числовой ID
___
>> RealProg:  но при этом более медленно по всей видимости

Более медленнее чего? Чем могло бы? Чем другие решения?
Для этого фирма Intel выпускает новые процессоры, а фирма Microsoft выпускает новые ОС. Фирма 1С работает над платформой, обеспечивающей удобство разработки, высокую скорость разработки прикладных решений, а не скоростью работы прикладных решений.

Когда реально нужна скорость работы, платформа 1С может обеспечить требуемый функционал, но рекордов от неё не ждите. Не ждите высшего рейтинга в шахматных программах или в полнотекстовом поиске. Это другие задачи для других платформ. Платформа 1С решает СВОИ задачи, для которых предназначена, и с ПРИЕМЛЕМОЙ скоростью.

RealProg: я не предлагал решать с помощью 1с шахматные задачи. Я предлагаю доработать 1С.

Стиль похож. Хотя Маня и "индекс" вещи не считающиеся )))

(182)
>>> Вопрос явно не к мисте. Обратись к разработчику типовых.>> RealProg: именно это я и делаю через данный форум

Этот форум никак не связан с фирмой "1С" и не влияет на разработки платформы 1С и типовых конфигураций.

это не Маня.

(185) Тогда он точно из Ростова

(182) > Это в 1С подчинён, а в реальной жизни не подчинён

Это новое слово в гражданском праве! Договор оказывается может быть ни с кем!

(182) > Всё дело в ключевых атрибутах и принципах нормализации. Для КЛАДРа ключевыми атрибутами являются строки (названия символов), а не числа (их некие коды).

Не, Вы явно с ручника не снялись! Еще раз повторяю - адрес слабо классифицируется. Поэтому и сделали его произвольного формата с заполнением по шаблону из КЛАДР.

Я задал выше Вам вопрос - Санкт-Петербург в Вашей классификации город? Или что?

(188)  Санкт-Петербург в Вашей классификации город? Или что? - а что есть другие варианты?

(189) Вы еврей? Иначе почему вопросом на вопрос отвечаете?

Так город это или что?

(189) А вы КЛАДР когда-нибудь видели?

(187) это пойнт Волшебника

(187) договор афферта, коллективный договор, договор право уступки (тройственный) и т.д.

вообще я выше писал почему адрес сделан строкой. И не только в 1С, а практически во всех системах которые использую КЛАДР - а других распространенных классификаторов нет.

С кладром самое главное чтобы его можно было делать внешним источником данных и держать в облаке, а не в каждой базе по копии :)

(187) Договор подчиняется закону, праву. Контрагенты подчиняются договору, а если не согласны, то в суд.

(194) Русский биллинг каждый раздел Кладра в отдельной таблице:
Города, регионы и т.д.

Отвечаю Джинну и остальным: Санкт-Петербург это город!

(198) Не только. Это ещё и регион.

(198) Потрясающе. Вы только что отказались от работы с единственным распространенным адресным классификатором. Так как города Санкт-Петербург в нем нет. А есть Регион "г. Санкт-Петербург".

(200) 200

(201) мазила

(197) см. (147)

(200) Я не отказывался от работы с КЛАДР. А Санкт-Петербург это все-таки город.

(204) С точки зрения реальной жизни, это особый город, а именно город федерального значения. Новая сущность.

(204) Областные центры это регионы. Неожиданно да?

(204) Я отлично понимаю, что КЛАДР-а вы никогда не видели.

(202) Не сотку, а двухсотку.

(206) В России только два города обладают таким статусом: Москва и Питер. Остальные центры регионов — это просто города.

(209) Тебе же сказали, Питер - это не город

(204) Если непонятно - то еще раз повторю. Практически во всех системах адрес это строка, ибо иначе при обновлении КЛАДР-а, у вас всё слетит. Так как он обратно несовместим. Ни по какому полю.

(206) Точно.

(193) Оферта - это только предложение. При акцептовании оферты договор считается заключенным и КОНКРЕТНЫМ контрагентом. Грубо говоря кассовый чек - Ваш договор с магазином.

В коллективном договоре стороной выступает коллектив в виде ОДНОГО контрагента. Такой договор подписывается представителем коллектива.

Договор уступки требования - это по сути ДВА договора. И с каждой стороной такого договора СВОИ обязательства.

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

В в Псковской области, которая регион, почти нет городов. Зато полно поселков и деревень. И многие вообще без улиц и домов. Чудненько?

А еще есть замечательные всякие военные городки федерального подчинения и пр. почтовые ящики.

Про буржуев с из собственной классификацией будет говорить? Или ну его на фиг?

КЛАДР вчерашний день, ща в моде ФИАС ))))

те же яйца вид сбоку )))

(210) Кто сказал? Почему я должен их мнение принять за истину?

Питер — это город федерального значения.
С точки зрения реляционных баз данных, а также с точки зрения разработчиков Классификатора Адресов России, а также с точки зрения Конституции РФ, город федерального значения <> просто город.

У тебя есть другое мнение? Круче мнения классиков БД, Конституции РФ и разработчиков КЛАДРа?

(213) ипотечный договор? там раб-ипотечник, банк, страховая, поручители... Иногда прописывают застройщика/продавца... Пишут всех

Нормализация - это ускорение доступа к данным.
В 1С немного другой подход - стандартизация - то есть иногда проще "держать все яйца в одной корзине" даже если они по структуре разные - но выбирать их сможет один и тот же алгоритм, а в случае нескольких таблиц придётся алгоритм модифицировать. Кроме того, хранение всех записей в одной таблице позволяет там же хранить итоги по группам.

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

О, наконец-то, кажись, дошло, что по мнению (0) "В 1с не соблюдаются правила нормализации баз данных "
неправильно сама нормализация сделана, а я все думал по теме - какие правила нарушаются ???
Ребята, давайте хранить данные в полном экскорте, нафига нам эта нормализация

(219) А что такое "полный экскорт"?

(220) - кортеж, сорри, это наш слэнг

(221) ну ты паразит. я ж всю википедию перерыл :)))

(0) Мля, ну толстый.......

(223) не. он не тролль. он даже 1500 заплатил за свою глупость.

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

Вот не хотел писать в эту уже заглохшую тему, но после прочтения еще одного поста на блоге просто не смог пройти мимо. Тут кроме 1С обсуждается вкратце и САП:
"Есть нелестные отзывы и об интерфейсе SAP, пишут что он очень устаревший и неудобный.
Даже книги по SAP в книжных магазинах стоят как правило 2, 3 тысячи рублей, что на наш субъективный взгляд тоже чересчур дорого.
Непонятно, почему, если как утверждают некоторые статьи SAP такой суперполезный, помогает оптимизировать бизнес, почему же SAP занимает такую малую количественную долю в среднем и малом бизнесе в России.
И на такую программу (SAP) выбрасываются сотни миллионов долларов в России."

Особо понравилось "Непонятно, почему, если как утверждают некоторые статьи SAP такой суперполезный, помогает оптимизировать бизнес, почему же SAP занимает такую малую количественную долю в среднем и малом бизнесе в России". Ребята жгут каленым железом.