|
|
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Доброе утро. Есть вопрос: имеется таблица Лицо с наиболее общими атрибутами любых лиц и таблички физических лиц и юридических, в которых сидит ссылка на соответствующую запись в таблицу Лицо. Тут встал вопрос: либо оставлять две таблицы либо слить физиков и юриков в одну таблицу и добавить поле типа: физик/юрик, а в триггере в зависимости от типа пасти значений полей, который должны быть null/not null у физиков/юриков соответственно. А как сделана аналогичная вещь у Вас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 10:05 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
У меня было две отдельных таблицы, одна для юриков, другая для физиков, но диапазоны ключей у них не пересекались. Например для юриков отрицательные, для физиков положительные. А в таблице договоров поле содержало соответствующее значение. (-) Нет связей между таблицами, целостность поддерживалось на уровне бизнес-логики. (+) Можно было описать любую ситуацию, договор заключен с физиком, с физиком, представителем юрика, с юриком. все, имхо ------------------------------------------------------- Заходи в саpай аккуpатно - могут быть сеpьезные гpабли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 10:36 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
А мне надо как раз обеспечить сквозную нумерацию физиков и юриков... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 10:43 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
А если появится третий тип ? Ну вдруг ! ИМХО: решение: одна таблица с признаком (но только не boolean). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 10:46 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Они и будут нумероваться непрерывно с -X до +Y. 0 - можно зарезервировать под код собственной фирмы или если собственных фирм несколько то выделить вокруг нуля диапазон от -100 до -1 для собственных сотрудников и от 0 до 20 для собственных фирм внутри холдинга. Потом диапазон в конечном счете будет не непрерывный, т.к. некоторых физиков или юриков потом могут удалить. все имхо, дело вкуса! ------------------------------------------------------- Заходи в саpай аккуpатно - могут быть сеpьезные гpабли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 10:49 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Одна таблица со сквозной нумерацией , общими атрибутами,служебной информацией и типом контрагента. Расшифровка типа - в отдельной таблице,набор флагов + дополнительные таблицы, специфичные для каждого типа(типов) контрагента + неспецифичные для типа контрагента таблицы (права доступа) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 11:49 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
To AlexeySH: именно так у меня сейчас и сделано (см. мой пост), а вот в чем минусы такого решения, плюсы и интересно обсудить. По-моему, при таком физическом дизайне более очевидна объектная иерархическая структура: лицо->юрик->банк, удобно использовать сквозную нумерацию. Других плюсов я пока не нахожу. Минусы вроде бы такие (не для меня): при появлении нового типа приходится добавлять новую таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 12:31 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
2 Shtock : Ну есть вариант с узкой длинной таблицей атрибутов. в плюсе - отсутствие необходимости править структуру при добавлении очередного ОКДПХЗХУ :) в минусе неоходимость сборки "записей" из атрибутов для отчётов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 13:07 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Ух, вякну и я... Если бы ты юзал Bold for Delphi (или ECO для всяких там C#, Delphi 8 и проч), то твоя проблема решилась бы сама собой - введением абстрактного класса Персона, и двух дочерних - Юридическое лицо и Физическое лицо. См. прилагаемую схему. Такие струтуры Bold обычно реализует в одной таблице - причем утверждается, что "Отображение представления родителя на его потомка увеличивает производительность при поиске в одном из дочерних классов, т.к. база данных для этого открывает только одну таблицу." Это примерно то, что реляционщики называют денормализацией. Особенность реализации - такая таблица содержит Id таблицы и Id класса, ну, для Вас (при обычном, без - Bold - овском кодировании) до кучи можно ввести "Сквозной номер". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 14:39 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Во, блин, нарисовал фигню... В Юридическом лице все атрибуты, конечно, "Специальные". Извиняюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 14:40 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
To mv: Как Вы уже думаю поняли из моих постов. у меня практически так и сделано. Немного offtopic, но: если я правильно если у меня иерархия 10 классов, в каждом из которых по 10-20 атрибутов и все это будет "Отображение представления родителя на его потомка увеличивает производительность при поиске в одном из дочерних классов, т.к. база данных для этого открывает только одну таблицу", то я поимею таблицу о 200 полях? Я боюсь, что размеры rollback-сегмента будут крупноваты, а так как Bold если я правильно понял, держит все это в памяти, то хватит ли ее? - это риторический вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 14:48 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Shtock... то я поимею таблицу о 200 полях? Я боюсь, что размеры rollback-сегмента будут крупноваты, а так как Bold если я правильно понял, держит все это в памяти, то хватит ли ее? - это риторический вопрос. 1. Неправильно понял. Bold не копирует всю структуру базы в память. Он ее так (описанным выше образом) хранит. Более того, Bold при работе не копирует все объекты базы в память. Хотя этого можно добиться. 2. У тебя действительно в модели бизнес - объектов 10 - уровневая глубина наследования? 3. Существет возможность настроить отображения как родителя - на потомков, так и наоборот. Или вообще все по отдельным таблицам разбросать. Тут имеет смысл рассматривать в контексте конкретной задачи, сервера СУБД, объемов данных и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 14:58 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Если не жалко, покажи примерчик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 15:08 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
4 уровня - обычная ситуация ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 15:32 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
как у меня: 3 таблицы 1 Лицо - содержит общее для юр и физ + 2 поля ссылка на Юр, ссылка на Физ 2 Физ - только то что относиться к Физ 3 Юр - только то что относиться к Юр соответственно признак получился сам собой. ЗЫ. а лица бывают 3 типов физ, юр и пбюл(имеет признаки и юр и физ) но можно 1 таблица на всю БД, с полями f1, f2,f3 в которую можно писать всё что угодно, причем здесь достигается любая гибкость, а не только то, что видов лиц может быть сколько угодно... (см. как работают в Scala) это дело вкуса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 18:00 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
mvА Scala - это что? Scala - это Что. есть такая ERP система. писаная в COM+ зря я ее упоминул в суе. Чур меня чур Не когда не стройте БД как они строят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 18:15 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> А мне надо как раз обеспечить сквозную нумерацию физиков и юриков Зачем, если не секрет? > или если собственных фирм несколько то выделить вокруг нуля диапазон от -100 > до -1 для собственных сотрудников и от 0 до 20 для собственных фирм внутри > холдинга. 100 и 20 - это такие магические числа? А почему не 10000 или 1000000? > Одна таблица со сквозной нумерацией , общими атрибутами, Позвольте поинтересоваться, какие атрибуты можно назвать общими для физического лица и юридического? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2004, 19:14 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
To guest_20040621: единая система идентификации любого клиента. Пример общего атрибута: ИНН и много еще, если глубже рыть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 09:06 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 11:31 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> To guest_20040621: единая система идентификации любого клиента. А зачем для этого сквозная нумерация? > Пример общего атрибута: ИНН Плохой пример. У меня, например, ИНН нет. И не предвидится. И не один я такой. Еще варианты? > и много еще, если глубже рыть. Вот я и прошу привести пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 15:09 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Плохой пример. У меня, например, ИНН нет. И не предвидится. И не один я такой. Еще варианты? Как минимум сквозной номер ))) (ну надо ему надо) адрес юридический (прописки), фактический... какой менеджер работает с клиентом. Дата создания. Размер скидок и много чего, зависит от бизнес модели. И по поводу не один я такой... Вы уверены? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 15:24 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Как минимум сквозной номер ))) (ну надо ему надо) Блин, да я и прошу объяснить, зачем. Зачем-то ведь это было сделано? > адрес юридический (прописки), фактический... Хех, уважаемый, Вы уверены, что юридический адрес это то же самое, что и прописка? Про фактический - это отдельная песня. Вы что под ним подразумеваете? > какой менеджер работает с клиентом. Дата создания. Размер скидок и много > чего, зависит от бизнес модели. Это не атрибуты физического или юридического лица. Это атрибуты ваших бизнес-процессов. > Вы уверены? Абсолютно. Во-первых, человек не с рождения становится налогоплательщиком, правда? Во-вторых, в странах, отличных от РФ, - другая система идентификации налогоплательщиков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 15:43 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Во-первых, человек не с рождения становится налогоплательщиком, правда? Во-вторых, в странах, отличных от РФ, - другая система идентификации налогоплательщиков. В некоторых культурах и понятия "юридическое лицо" нет. Ну и что ? Вы в своих проектах все сущности обобщаете до космических масштабов ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 16:11 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
В разрабатываемой системе должна (это требования бизнеса) быть сквозная нумерация. Ведь программист разрабатывает ПО не для себя... Задача специфична для России в условиях этой задачи ИНН является необходимым. По поводу "не сразу становится налогоплатильщиком" - я и не моделирую ЖЦ человека, я моделирую нужные бизнесу (а не мне) вещи. Ну не устраивает такой общий атрибут как ИНН, а страна устроит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 16:12 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
чукча не читатель чукча писатель... ясно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 16:14 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
To funikovyuri : Не понял Вашей фразы: к чему она? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 16:24 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
это я так реагирую на игнор моего поста ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 18:10 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Вот вам общий атрибут: "Особый". Всю жизнь меня просили вводить такой атрибут для разных сущностей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 18:16 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> В некоторых культурах и понятия "юридическое лицо" нет. Под "культурой" Вы имеете в виду социум? Государство? Экстерриториальные образования? Как этот факт - если он имеет место - связан с текущим обсуждением? > Вы в своих проектах все сущности обобщаете до космических масштабов? Я не держу принципиально разные сущности в одной таблице. И уж тем более не призываю тиражировать ошибки проектирования. Какие космические масштабы? Какие обобщения? > В разрабатываемой системе должна (это требования бизнеса) быть сквозная > нумерация. Что значит "требования бизнеса"? Это в ТЗ так записано? > Задача специфична для России в условиях этой задачи ИНН является > необходимым. Что значит "специфична для России"? Я знаю один класс задач, действительно специфичный для РФ, - обслуживание государственных стуктур. Тогда не совсем понятно, о каком бизнесе Вы ведете речь, - государственные предприятия коммерческой деятельностью не занимаются. Закон запрещает. Кроме того, необходимость регистрации ИНН не является поводом для противоестественного со всех точек зрения объединения разных сущностей в одной таблице. > я моделирую нужные бизнесу (а не мне) вещи. Неправильно моделируете. > Ну не устраивает такой общий атрибут как ИНН, Это Вы считаете его общим атрибутом. На самом деле он таковым не является. Физическое лицо не обязано иметь ИНН, а юридическое (в т. ч., кстати, и ПБОЮЛ) обязано. > а страна устроит? Предприятие может быть зарегистрировано как субъект предпринимательской деятельности в некоторой стране, может иметь филиалы в разных странах, может иметь производственные мощности, представительства, сервисные центры etc в определенной стране/странах; человек может иметь гражданство определенной страны/стран, может проживать в определенной стране, но собственно страна являться общим атрибутом юридического и физического лица не может. Вы писали об общих атрибутах, правда? Т. е., упоминали их во множественном числе. Не сочтите за труд, перечислите, пожалуйста, те атрибуты, которые Вы считаете общими для юридического и физического лица. Если Вы будете приводить их по одному, это займет много времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 18:19 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Вот так. Все слова фиксируются. Как для страшного суда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 18:21 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
вопрос звучал так. ShtockА как сделана аналогичная вещь у Вас guest_20040621 если не затруднить скажите как у вас. кстати, вы не одназначно выразились ИНН у вас нет, или нет ИНН в таблице физ или что там у Вас есть(как я понял в начале, т.к. если предположить обратное то это противоречит действительности, вы можите его не знать) далее 1. Физическое лицо имеет ИНН 2. Адрес прописки и юр адрес это разные вещи ... в жизни. 3. фактический - адрес фактического проживания, адрес головного офиса, т.е. то куда письма слать. 4. страна, гм а почему нет. (это часть Юр адресса) Например никто не емеет отношения с Siemens, кто-то имеет отношения с ООО (или как там) Сименс, страна Россия. З.Ы. правда в том что у меня в этой общей таблице, большаая часть полей имеет отношение к сущности Клиент. А то что вынесено в Физ, Юр - это те поля которые строго Null в зависимости от типа клиента. Те признаки которые могут быть и там и там, тоже добавлены в эту общую. Вот и все. Ваша правда в том что не стоит объединять разные сущности. Моя в том - что мне этого достаточно. Можно конечно и более строго подойти не мешая, но зачем мне отмерять микромером, что бы потом отметить мелом, для того что бы разрубить топором. И если все делить на сучности то таблиц физ и Юр тоже не должно существовать, за место каждой из них должны быть 5-6, тока зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 19:28 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Ответ на вопрос можно получить только на объекте... Если отличия Физиков от Лири... Юриков не значительны, то можно их держать и в одной таблице. При этом проблема единой уникальной идентификации ничуть не станет легче. Если же различия существеннее - тут на атрибуты надо смотреть, - то таблицы бы разделил - Физики и Юрики, и поддерживал бы три объекта для доступа: Физики_Вью, Юрики_Вью, Лица_Вью. При чем по моим проектам (с 89 года по 2001 писал комплексы под заказ) этот вопрос оказался несущественным. А вот многое из обсуждавшегося в ветке было очень существенным: 1. Зачем нужен объект "банк-эмитент". Это что, не банк? Нужен не объект, а возможность орагнизации иерархии. 2. Целостность на уровне бизнес-логики намного гибче, кажется некрасиво, но на самом деле чрезвычайно эффективно. 3. Удаление гораздо лучше делать через пометку "неактивен", чем серез реальное удаление. Впрочем, это очень зависит от общего дезайна проекта. 4. В реляционных системах наследование не есть очень хорошо. Впрочем, если система небольшая по объемам - то сойдет. 5. А вот и самое проблематичное. Казалось бы паспорт - это уникальный атрибут физ. лица. Но нет - женщина вышла замуж, в государстве поменяли паспорта, понадобилось знать заграничный. Масса других изменений. Все это мелкие проблемы в чисто оперативной системе, когда нужно знать "чего у нас есть на складе". Но стоит только хранить данные в системе за несколько лет... Так что ответ на вопрос можно получить только на объекте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 19:51 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> кстати, вы не одназначно выразились ИНН у вас нет Факт в том, что общим выбран атрибут, таковым не являющийся. А чего и как у меня - согласитесь, дело десятое. > 3. фактический - адрес фактического проживания, адрес головного офиса, т.е. > то куда письма слать. Согласитесь, почтовый адрес и местожительство - как бы разные вещи. И головной офис - понятие неоднозначное. > 4. страна, гм а почему нет. (это часть Юр адресса) Потому что для разных сущностей этот атрибут интерпретируется по-разному. Адрес - например, почтовый - можно понимать как атрибут. А отдельно страну - нет. > Ваша правда в том что не стоит объединять разные сущности. Да нет тут никакой моей правды. Есть правила проектирования. > Моя в том - что мне этого достаточно. Это плохой подход: в следующем проекте этого не будет достаточно и придется все переделывать. И так - для каждого нового проекта. Фишка в том, чтобы каждый следующий проект уточнял/дополнял основную структуру данных, - во-первых, это экономит время, во-вторых - деньги. А денормализовать или убрать детали - много проще, чем писать заново. > таблиц физ и Юр тоже не должно существовать, за место каждой из них > должны быть 5-6, тока зачем? Почему не должны существовать? Таблица физических лиц - практически стандартная. Вот с юридическими есть нюансы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 20:27 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> не значительны, то можно их держать и в одной таблице. Еще раз, для особо не желающих слушать: это _разные_ сущности. Абсолютно. Т. е., ничего похожего. Никакого повода держать их в одной таблице нет. Вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2004, 20:31 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
To funikovyuri: Извините, что не ответил. Это так сделано у Вас или Вы бы так спроектировали БД для данной ситуации? To guest: 1. физик и юрик - не "принципиально-разные" сущности. В контексте бизнес-задачи это просто различные делегаты сущности Клиент. 2. Да, это написано в ТЗ 3. ИНН необходим для любого вида ведения бизнеса с человеком: нет ИНН - не заплатишь налоги, не сдашь отчет в налоговую инспекцию, ..... 4. филиал предприятия - отдельный клиент, поэтому довод что филиал может быть в другой стране не уместен 5. для текущих задач учета имеет место где человек проживает. Конечно, я могу хранить инфу даже в какие страны он ездит в отпуск, но а мне это надо!? Еще раз повторяю: должна быть некая дельта точности моделирования. Мне такое не надо. To Pi: иерархия приведена чисто для примера. В БД надо думать хранится все не так. Это иерархия (наследование) на уровне бизнес-логики. По поводу "уникальности паспорта": именно для этого и введен уникальный код Клиента с так пугающей почему-то некоторых сквозной нумерацией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 09:32 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Shtockименно для этого и введен уникальный код Клиента с так пугающей почему-то некоторых сквозной нумерацией. Тут очень надо четко понимать что есть "сквозная нумерация". Большинство СУБД имеет встроенный механизм для поддержки уникальной нумерации, но Ваш программист потратит много ресурсов - и своих, и СУБД, - для поддержки сквозной нумерации в общепринятом понимании - монотонно возрастающей последовательности целых чисел без пропусков. Самое печальное, что я не знаю реально сущностей, которым этого бы требовалось. Хотя еще в 88 году работал с нумерованными бланками строгой отчетности на спиртзаводе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 13:45 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Фишка в том, чтобы каждый следующий проект уточнял/дополнял основную структуру данных, - во-первых, это экономит время, во-вторых - деньги. Теперь понятно. Замахиваетесь на большое. Тогдба следовало сначала определить себе нишу на рынке, потом - конкурентов. А потом обойти инсталляции конкурентов и выяснить, что в них плохого. Или хорошего. Второй подход тоже продуктивен - посмотреть, как делают гранды, и сделать примерно так же. Тогда можно конкурировать по цене. Что же касается надежд на преемственность проектов, то лично мне очень по душе мудрость одного руководителя компании-разработчика - "Желания клиента не мотивированы". Засим - успехов! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 13:52 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> 1. физик и юрик - не "принципиально-разные" сущности. Вы ошибаетесь. Изучайте предметную область. > 3. ИНН необходим для любого вида ведения бизнеса с человеком: Вы ошибаетесь. Изучайте предметную область. > 4. филиал предприятия - отдельный клиент, Вы ошибаетесь. Изучайте предметную область. > именно для этого и введен уникальный код Клиента с так пугающей почему-то > некоторых сквозной нумерацией. Она никого не пугает. Это просто банальная ошибка. > Тогдба следовало сначала определить себе нишу на рынке, потом - > конкурентов. Хм... проблема в том, что а) рынка как такового нет, б) следовательно, и конкурентов нет. Говоря о рынке, принято иметь в виду программные продукты, а никак не качество описания информации. > Второй подход тоже продуктивен - посмотреть, как делают гранды, и сделать > примерно так же. Тогда можно конкурировать по цене. Не согласен. "Гранды" могут делать вообще все, что вздумается (возьмите ту же 1С, которую хают все, кому ни лень, но не прекращают ей пользоваться); повторять их ошибки - неинтересно. > Что же касается надежд на преемственность проектов, то лично мне очень по > душе мудрость одного руководителя компании-разработчика - "Желания > клиента не мотивированы". Я не полностью, неправильно сформулировал то, что хотел. Есть некоторая абстрактная структура данных, которую можно использовать в качестве исходной для любого проекта, - вот она-то и уточняется от проекта к проекту. А что при этом отдается заказчику - дело десятое (как я говорил, упростить существующую структуру намного легче, чем написать заново). Кстати, по поводу приведенной цитаты: более продуктивной мне кажется задача _формировать_ желание клиента, а не следовать ему. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 15:56 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Вы просто всех за интриговали, поэтому я еще раз прошу пару слов о том как у вас устроены сущности физ. и юр. Пока Вы нам это не явите - говорить не о чем и ветка окончательно уйдет во флейм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 18:56 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Я не хотел бы вступать в спор о том являются ли физики и юрики подтипами супертипа клиент - imho это алхимия. Я просто приведу отрывок из книги глубоко мною уважаемого Р. Мюллера где описываеться отображение отношения UML generalization (то что в ОО-языках реализуется с помощью наследования) на реляционную модель. Фактически в ней рассказывается как реализуется наследование в РСУБД. Я знаю что тоже самое известно и для ER-нотации - просто я привык работать в терминах UML и считаю что в данном случае выбор между ними не принципиален... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 19:20 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Вставлю свою пару слов. Является ли ФЛ и ЮЛ подтипами одного и тогоже супертипа (клиент (Customer) ? Естственно да. По-моему во всех книжках по теори БД описывается связь is a (является экземпляром типа). Чем отличается ЮЛ от ФЛ? А тем, что ЮЛ представляют одно или несколько ФЛ, которые занимают определенные должности в ЮЛ, и причем на основани доверенностей, устава или др. документов. И еще маленькая деталь - Клиенты бывают как резидентами, так и нерезидентами. У Нерезидентов такие понятия как ИНН ОКПО, ОКОНХ КЛАДР и пр. могут отсутствовать. Опять же, если возьмем Бразильский адрес , адрес в США, и в России, то все эти типы адресов будут иметь разную структуру. Т.е. сттуктура сущности "адрес" является функцией от атрибута "страна". Для ФЛ, И ЮЛ характерно также понятие ИМЯ (полное и краткое наименование), котрое может меняться во времени, причем довольно часто. (девушка вышла замуж/развелась). Изменили устав Организации, и следом поменяли краткое и полное наименование. Следует так же заметить что атрибуты фамилия, имя, отчество - присутствуют только у славян. Если возьмем какого-нибуль Хосе Луиса Альберто Карлоса из Бразилии, то все будет по-другому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 19:56 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> пару слов о том как у вас устроены сущности физ. и юр. Imho, тред не о том, как, что и где я реализовал, правда? Писал я для того, чтобы x Guest (т. е., человек, открывший топик) не пользовался вредными советами. > Является ли ФЛ и ЮЛ подтипами одного и тогоже супертипа (клиент (Customer)? Естственно да. Можно обосновать это утверждение? Кроме того, было бы крайне любопытно, почему это естественно. Можно своими словами. Хинт: это соответствует действительности только в некоторых случаях. > А тем, что ЮЛ представляют одно или несколько ФЛ, которые занимают > определенные должности в ЮЛ, и причем на основани доверенностей, устава > или др. документов. Плохое определение. Юридическое лицо может иметь генерального директора и главного бухгалтера - и все. Причем, эти должности может совмещать один человек. Кроме того, есть особая форма - предприниматель без образования юридического лица, который во многих (не во всех и не всегда) случаях приравнен к юридическому лицу. > Для ФЛ, И ЮЛ характерно также понятие ИМЯ (полное и краткое > наименование). Вы считаете, что название предприятия и ФИО человека - близкие понятия? Позвольте с Вами не согласиться. Их источник, суть и решаемые ими задачи существенно различны. И регламентируются они (по крайней мере, в РФ) абсолютно разными нормативными документами. Их структура, употребимость и некоторые другие атрибуты существенно различны. Если в первом приближении предприятие однозначно идентифицируется как (название + идентификатор налогового учета (+ место постановки на налоговый учет)), то человек - (ФИО + дата рождения + место рождения). > Следует так же заметить что атрибуты фамилия, имя, отчество - присутствуют > только у славян. У арабов вроде тоже есть отчества (т. е., часть имени, которое можно интерпретировать как отчество?)? Но большинство - согласен - обходится именем и фамилией. Причем, имен может быть несколько (и употребляться они могут по-разному). Порядок следования имени и фамилии (и, например, возможность употребления сокращений или отдельно фамилии/имени) зависит от страны происхождения человека (для простоты положим так, на самом деле все чуть сложнее). В некоторых случаях используются суффиксы (например, младший (junior)), или префиксы (например, титул (сэр)). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 21:34 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Что то я опять не понимаю Вы всерьез намерены точно описать реальность ? Это невозможно впринципе Можно моделировать реальность с различной степенью приближения И эта степень определяется постановкой задачи Когда рассчитывают движение жидкости в трубопроводе не рассматривают движение каждой молекулы и уж тем более не используют квантовую механику ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 10:06 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
ну а если посмотреть в ЕГРЮЛ (Единый Государственный Реестр Юридических Лиц) который формирует само МНС то там а небольшого числа юриков нет вообще ИНН а у приличного числа ИНН вообще дублируется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 10:33 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
У нас сделано отношением подкатегории : Общая таблица с общими атрибутами (к ней также привязаны таблицы для множественных атрибутов), и две таблицы для специфичных атрибутов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 11:06 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Imho, тред не о том, как, что и где я реализовал, правда? Писал я для того, чтобы x Guest (т. е., человек, открывший топик) не пользовался вредными советами. Нет, не правда. Смотри тему, начало темы. Для меня это очень даже принципиально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 11:17 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> пару слов о том как у вас устроены сущности физ. и юр. Imho, тред не о том, как, что и где я реализовал, правда? Писал я для того, чтобы x Guest (т. е., человек, открывший топик) не пользовался вредными советами. gues_20040621, уже все поняли, что Вы абсолютно правы, и переспорить Вас не получится. Только пожалуйста опишите то, что Вы реализовали. Если своего нет, то опишите, с какой чужой реализацией вы знакомы. Опишите хоть какую-нибудь схему данных, которая реально работает и которую Вы считаете правильной. Я прям заинтригован. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 11:40 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Вы всерьез намерены точно описать реальность? > Это невозможно впринципе Если Вы не сталкивались с информационными системами, это не значит, что их нет в природе. Никто не описывает абстрактную реальность. Исключительно предметная область, ничего более. Нельзя тренера МЮ назвать Алекс Фергюсон, понимаете? Нужно непременно сэр Алекс Фергюсон. Если бы Вы были выпускающим редактором РИА "Новости", Вас бы за такой ляп премии лишили как минимум. Мало того, что он обидеться может, так это еще и просто безграмотно. > ну а если посмотреть в ЕГРЮЛ Госструктуры не умеют работать с информацией. Вообще. См., например, базу ГТК - это просто... очень плохо. > опишите то, что Вы реализовали Извините, нет. Если интересно, возьмите сообщение [963082], - там практически все основные таблицы для физических лиц можно найти (о чем-то говорилось в предыдущих сообщениях). Плюс правила. Плюс локализация. Плюс разделение доступа. Плюс хронология изменений. Получите адекватную в первом приближении структуру данных для регистрации физических лиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 16:17 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 НИИ очень очень очень сложных процессов, я угадал? где еще в прикладной системе может пригодиться посылка что Ф- лицо и Ю- лицо разные сущности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 16:38 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> НИИ очень очень очень сложных процессов, я угадал? Нет. Если Вы внимательно прочтете написанное, то наверняка увидите, что писал я об очень простых вещах. Тривиальных. Вы знаете о них вряд ли меньше моего. > где еще в прикладной системе может пригодиться посылка что Ф-лицо и Ю-лицо > разные сущности? Это не посылка. Это факт. Замечаете разницу? А пригодиться оно может абсолютно в _любой_ прикладной системе. Более того, если база данных не содержит структуры данных для описания физических лиц - а они там есть - это _абсолютно безграмотно спроектированная_ база данных. За сим позвольте закончить обсуждение, - относительно основного вопроса, надеюсь, все изложил более чем доступно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 17:57 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
просто треп какой-то... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2004, 18:48 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Господа, я вчера отсутствовал, поэтому только сегодня все изучил и понял. что разговор о выяснении достоинств и недостатков 2-х предложенных подходов превратился в непонятно что. С большинством из Вас я полностью согласен, но этот топик уже превратился банальный флейм. Всем спасибо, топик закрыт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2004, 08:54 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Блин, Физики и Юрики - это вообще - моя любимая тема. Сколько уже копий по этому поводу сломано было. Сколько еще поламаем. сорри за задержку - я в отпуске. Физики и Юрики - это типы одного супертипа потому, что они имеют однотипные атрибуты, однотипные связи, и над ними можно проводить однотипные операции. Общие атрибуты, - Список адресов, Банковские счета, каждое лицо имеет наименование, которое может быть представлено в виде одной строки символов (я называю кратким наименованием), каждое лицо имеет дату рождения, и дату смерти (если хотите). Каждое лицо может быть резидентом и нерезидентом, а следовательно может иметь ИНН и прочие чисто российские атрибуты. Каждое лицо может в моей конкретной ситуации (я занимаюсь сейчас страхованием) выступать в роли: страхованиеля,должника, плательщика, получателя, выгодоприобретателя, виновника страхового случая и пр. И что? прикажете мне писать код для всех этих случаев отдельно для ЮЛ и ФЛ? Да я лучче застрелюсь. А если взглянуть еще шире. Между ЮЛ и ФЛ можно ввести такое понятие как "отношение" или "состоит в связи". Например: и ЮЛ и ФЛ могут быть акционерами ЮЛ. ЮЛ может быть филиалом другого ЮЛ.ФЛ может работать в ЮЛ. И ЮЛ и ФЛ могут быть - банально- клиентами другого ЮЛ и ФЛ или по крайней мере - партнерами. Если возьмем отношения чисто между ФЛ - то тут несколько сложнее. Есть такое понятие как родственные отношения, которое можно описать направленным графом. А если возьмем такое понятие как "знакомый" - это можно было бы описать ненаправленным графом. Наверняка такие структуры используются в системах безопасности для поиска возможных контактов. А вообще применений такой системе можно было б найти множество. А теперь представим, что узелы в таком графе находятся в рвзных таблицах. Лучше сразу повеситься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2004, 14:44 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
автор Юридическое лицо может иметь генерального директора и главного бухгалтера - и все. Причем, эти должности может совмещать один человек. От тут вы совершенно не правы. Есть такое понятие - карточка образцов подписей, которая заверяется нотариально. Есть также понятия "право первой" и "право второй" подписи. А какие должности занимают подписывающие - дело десятое. Более того, право подписи, как и карточка подписей действует определенное время. Конечно в постом случае можно добавить эти атрибуты конкретно к каждому договору и не патиться. Тут уж пусть каждый выбирает по себе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2004, 15:01 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
To gardenman: у меня как раз в бд присутствует понятие "отношение". Очень удобно описывать связи физиков и юриков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2004, 09:26 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Госструктуры не умеют работать с информацией. Вообще. См., например, базу ГТК - это просто... очень плохо. и не говори... это ужас как они хранят информацию... чёрт ногу сломит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2004, 14:37 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
gardenman Физики и Юрики - это типы одного супертипа потому, что они имеют однотипные атрибуты, однотипные связи, и над ними можно проводить однотипные операции. Как бы флейм, но все же... Юридически каждое физическое лицо является юридическим! Это надо знать. И потому любое физическое лицо является подтипом юридического. В это ветке, по-момему, спутали понятия юридического лица и субъекта предпринимательства. Из-за этого и сыр-бор. Да, субъект предпринимательства - это уже нечто иное, чем только юридическое лицо, и поэтому его можно в некоторых предметных областях описывать отдельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2004, 20:10 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Юридически каждое физическое лицо является юридическим! Дружище, надо чаще отдыхать. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2004, 21:52 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Юридически каждое физическое лицо является юридическим! Дружище, надо чаще отдыхать. ;) Учите матчасть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2004, 15:26 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Учите матчасть Хм... если это имитация наличия глубокой мысли в утверждении "Юридически каждое физическое лицо является юридическим", то неудачная, поскольку ее там не просто нет, а и быть не может. ;) Дружище, не вводите в заблуждение окружающих, - тем более, что окружающие - это в основном люди с незаконченным образованием или вовсе без оного. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2004, 21:48 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
что окружающие - это в основном люди с незаконченным образованием или вовсе без оного. ;) А! Вот теперь все понятно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2004, 14:03 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Учите матчасть Хм... если это имитация наличия глубокой мысли в утверждении "Юридически каждое физическое лицо является юридическим", то неудачная, поскольку ее там не просто нет, а и быть не может. ;) Дружище, не вводите в заблуждение окружающих, - тем более, что окружающие - это в основном люди с незаконченным образованием или вовсе без оного. ;) Я лишь пытался высказать покороче тот факт, что любое физическое лицо является субъектом прав. Субъектом прав явлется и юридическое лицо. А как называется более общий вид - субъект права? Лицо? Назывется оно юридическое лицо, в широком смысле сова. Да, Гражданский кодекс РФ в определениях противопоставляет этих субъектов - но это лишь подчеркивание РАЗЛИЧИЙ в двух подтипах одного типа. Такое определение свойственно не всем юридическим текстам. Например, ко мне лично текст ГК РФ отношения не имеет ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2004, 17:22 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Я лишь пытался высказать покороче тот факт, что любое физическое лицо > является субъектом прав. С оговорками - согласен. > Субъектом прав явлется и юридическое лицо. Хех, это другие права. Для гражданина основной набор прав - это Конституция. Для предприятия - Закон об акционерных обществах (не совсем так, но для простоты будем считать, что так). Кроме того, по большому счету человек вообще не обязан вступать с государством в какие-либо отношения (а основной набор прав и обязанностей проистекает именно из наличия отношений человека и государства), равно как и может вступать в отношения сразу с несколькими государствами. Предприятие есть некоторое объединение (таких же предприятий или физических лиц с предприятиями), созданное для решения _уставных_ задач. Для предприятия _обязательна_ государственная регистрация. Более того, предприятие не может существовать вне правового поля. Выше я писал, что предприятия и физические лица однозначно идентифицируются совершенно по-разному (т. е., в одном случае основную роль играет некоторый идентификатор, _присваиваемый государственной службой_, в другом - совершенно естественные _правила_ именования). Неужели разница не очевидна? > Да, Гражданский кодекс РФ в определениях противопоставляет этих субъектов Я тоже могу написать кучу бумажек и ссылаться на них, - что это докажет? > но это лишь подчеркивание РАЗЛИЧИЙ в двух подтипах одного типа. Отнюдь. _С точки зрения государства_ - конечно, разница небольшая: и предприятие, и обычный человек представляет интерес как налогоплательщик. Но это только одна из возможных ролей человека, - почему я должен считать ее основной? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2004, 17:58 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Хех, это другие права. а вы про какие права? а как например с правом на владение недвижимостью? почему я должен считать ее основной? а вы пытаетесь смоделировать все? рискну предположить, что основную, в таком случае, вы не найдете. естественно, как я полагаю, нужно исходить из того, что вы моделируете. например моя предметная область предполагает некое общее между Физики и юрики . а ваша? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2004, 09:53 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Ни как не могу понять причин спора. Если рассматривать различие ФЛ и ЮЛ в глобальном плане, то имхо это разные сущности. Но при проектировании принято танцевать от задачи . Реализация и в том и в другом виде имеет право на существование в контексте задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2004, 10:52 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 и обычный человек представляет интерес как налогоплательщик. Но это только одна из возможных ролей человека, - почему я должен считать ее основной? Еще раз, и помедленнее - речь шла о понятии субъекта вообще. В частности - да, например, взятый под опеку идиот имеет совсем не те права, что полноправный гражданин. Кстати, а куда Вы бы отнесли имеющиеся сегодня во многих цивилизованных государствах юридические "морды"? Простите за слабый каламбур, я имел в виду животных, в первую очередь домашних. В украинском языке, кстати, это легче было бы объяснить - там используется термин "особа". Но украинским активно я не владею. Сегодня в российских актах я не нашел общего термина, но в русском лет 25 назад он был, и имел название "юридическая особа". Жаль, что на юридический текст того времени ссылку я дать нем могу. Кто-то здесь в этой ветке пытался утверждать, что хочет построить систему на все случаи жизни. Так вот, я набрался смелости утверждать, что для ТАКОЙ системы - если продолжить логику автора, - должен быть один ОБЩИЙ тип, Юридическое Лицо или Субъект Юридического Права, или еще как-то. Что же касается западной ERP системы с которой я работаю, и которая конкурирует с SAP по функциональному охвату, то там есть около 7 независимых сущностей, которые имеют общие подчиненные сущности, например, Почтовый Адрес, Банковский Счет. Успехов! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2004, 14:29 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> рискну предположить, что основную, в таком случае, вы не найдете. Правильно, об этом можно говорить только в контексте задачи. Проблема не в том, чтобы ее найти, а в том, чтобы саму сущность адекватно описать. > Еще раз, и помедленнее - речь шла о понятии субъекта вообще. У-у-у... давайте определимся с терминологией. Что значит "субъект вообще"? > В частности - да, например, взятый под опеку идиот имеет совсем не те права, Это понятно. Речь о том, что физические и юридические лица имеют в общем случае _разный_ набор атрибутов (ничто не мешает атрибутам совпадать _в частном случае_). А Вы на основании совпадений в частных случая делаете вывод о том, что это сущности одного класса. Это ошибка. > Сегодня в российских актах я не нашел общего термина, но в русском лет 25 > назад он был, и имел название "юридическая особа". И что? Термины придумали люди исключительно для своих задач и в общем случае они не обязаны адекватно отражать сущность. Хороший пример, кстати, - изменился общественный строй и отпала необходимость в термине. > для ТАКОЙ системы - если продолжить логику автора, - должен быть один > ОБЩИЙ тип, Юридическое Лицо или Субъект Юридического Права, или еще > как-то. И как это противоречит сказанному мной? ;) > Что же касается западной ERP системы с которой я работаю, и которая > конкурирует с SAP по функциональному охвату, то там есть около 7 > независимых сущностей, которые имеют общие подчиненные сущности, > например, Почтовый Адрес, Банковский Счет. А что, SAP - это эталон? Или Ваша ERP система - эталон? ;) Перечислите, пожалуйста, эти семь (если я правильно понял буквосочетание "около 7") независимых сущностей. А я постараюсь показать, где именно при проектировании супер-пупер западной ERP системы была допущена ошибка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2004, 15:34 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621. А я постараюсь показать, где именно при проектировании супер-пупер западной ERP системы была допущена ошибка. Ошибка - это этим заниматься. Они продали софта на миллиарды долларов. А Вы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2004, 19:15 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Они продали софта на миллиарды долларов. А Вы? Они нашли лохов, которые заплатили им миллиарды долларов. ;) А я? А я - нет, не нашел. Не искал потому что, наверное. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2004, 20:36 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Они продали софта на миллиарды долларов. А Вы? Они нашли лохов, которые заплатили им миллиарды долларов. ;) А я? А я - нет, не нашел. Не искал потому что, наверное. ;)) Попробуйте. Это изменит многое в Вашей жизни. В моей - поменяло кардинально. Не помню ктоЗрелый возраст - это такой возраст, когда человек уже достаточно стар, чтобы осознавать сделанные ошибки, но еще достаточно молод, чтобы делать новые ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2004, 13:39 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Попробуйте. Это изменит многое в Вашей жизни. В моей - поменяло кардинально. Зачем? Бабла заработать? Спасибо, на жизнь мне хватает. ;) Обслуживать чью-то поделку за пятьсот (тысячу, полторы) убитых енотов - предел мечтаний для Вас? ;) Скучно. Мне моя работа нравится. Например, потому, что я могу сказать Вам или таким же, как Вы, представителям покупателей мегаподелок: этот кусок дерьма писан убогим(и) индусом(ами), он (кусок дерьма, конечно, индус вроде как и ни при чем, - он выполнил работу согласно техническому заданию) чреват геморроем здесь, здесь и еще вот здесь, он содержит критически важные ошибки там-то и там-то. ;) А здесь проектировщики откровенно натупили, и вот такого функционала при всем желании не получить. ;) Дружище, всегда полезно представлять, что именно ты покупаешь и чем (кроме денежных средств) за это платишь. Не бывает абсолютных решений - как было справедливо замечено в этом треде - бывают оптимальные. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2004, 14:43 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Попробуйте. Это изменит многое в Вашей жизни. В моей - поменяло кардинально. Зачем? Бабла заработать? Спасибо, на жизнь мне хватает. ;) - Папа, папа, а правда тебя звали Неуловимый Джо? - Да, сынок!!! - Ух ты! А как тебе это удавалось!? - Да так... нието не ловил... Из фольклора ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2004, 16:27 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Из фольклора ;) Дружище, избавляйтесь от совкового менталитета. Иначе так и будете до пенсии за три рубля чужое дерьмо администрировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2004, 22:47 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Речь о том, что физические и юридические лица имеют в общем случае _разный_ набор атрибутов (ничто не мешает атрибутам совпадать _в частном случае_). А Вы на основании совпадений в частных случая делаете вывод о том, что это сущности одного класса. Это ошибка.Если продолжить эти рассуждения, то и филическое лицо guest_20040621 и физическое лицо Pi (извини Pi :) имеют разный набор атрибутов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2004, 09:48 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
А вот, кстати, новость из Днепропетровска: некто - физическое лицо в полном смысле, - по религиозным причинам отказывается получить идентификационный код. Налоговая администрация, в свою очередь, закрывает его предпринимательскую деятельность - получите код, мы разрешим Вам работать. Налицо факт, что здесь физическое лицо явно субъект предпринимательской деятельности. И что - он все равно по-прежнему разделен непреодолимым забором от предприятий и прочих субъект предпринимательской деятельности в обсуждаемой супер-пупер-постановке-на-все-случаи-жизни ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2004, 21:06 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Глупости вы тут городите про одну таблицу - скажите каким боком к доверенности будет относится ваша сущнось "Юр лицо" к довереннности в которой физлицо являющееся физлицом и просто сотрудником будет относится? Что лепить залепухи ? Юрлицо есть юрлицо, а физлицо есть физлицо и только должна существовать сущность лицо в которой только идентификаторы этих сущностей, а также есть сущность штат в которой поле-ссылка на сущность персона и в сущности физлицо тоже поле-ссылка на сущность персона Остальное либо от псевдо экономии либо от незнания предметной области Заметте ведь тут обсуждалось лишь одна сфера использования этих сущностей, а в другой сфере эти сущности должны быть подклассами других классов, и как тогда вашу единую таблицу рвать на немецкий крест? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 22:57 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Более того, предприятие не может существовать вне правового поля.Некоторые холдинги успешно этим занимаются. В правовом поле действуют входящие в них предприятия. А некоторых потребителей , с другой стороны, интересует сводный баланс взаиморасчетов с Васей , которому принадлежит энное количество юридических лиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 11:13 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Некоторые холдинги успешно этим занимаются. Уточните, что Вы имеете в виду. Если криминальные структуры, то хм... не думаю, что речь может идти об автоматизации. Если просто холдинги со сложной структурой акционерного капитала, - то здесь все вроде в рамках права (не обязательно российского). А если, скажем так, "неформальные" холдинги (масса ситуаций, когда официально невозможно получить сведения об акционерах), - готовых рецептов, конечно, нет. > некоторых потребителей ... интересует сводный баланс Можно подробнее? Потребитель - это МНС? Антимонопольный комитет? Конкурентные структуры? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 12:01 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Некоторые холдинги успешно этим занимаются. Уточните, что Вы имеете в виду. Если криминальные структуры, то хм... не думаю, что речь может идти об автоматизации. Если просто холдинги со сложной структурой акционерного капитала, - то здесь все вроде в рамках права (не обязательно российского). А если, скажем так, "неформальные" холдинги (масса ситуаций, когда официально невозможно получить сведения об акционерах), - готовых рецептов, конечно, нет. > некоторых потребителей ... интересует сводный баланс Можно подробнее? Потребитель - это МНС? Антимонопольный комитет? Конкурентные структуры? ;)Конечно, неформальные холдинги в обоих случаях - далеко не все из них юридически существуют. Подозреваю, что за последние годы мало что в данной области изменилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 12:14 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621государственные предприятия коммерческой деятельностью не занимаются. Закон запрещает. Закон разрешает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 12:17 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Закон разрешает. Это кастрированная, не полноценная коммерческая деятельность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 12:27 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Закон разрешает. Это кастрированная, не полноценная коммерческая деятельность.В данной системе - не более неполноценная, чем та, что Вы подразумеваете под некастрированной. Попробуйте создать ИТ-предприятие, взяв кредит с целью осуществить начальное финансирование разработки гениального софта - этому предприятию с большой вероятностью вменят налоги по аналогии с первой попавшейся компанией, и плевать что она уже десять лет как работает и развивается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 12:45 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> В данной системе - не более неполноценная, чем та, что Вы подразумеваете Я хотел сказать, что правовая база - различна. Вы же помните, как и для чего создавались ?УПы, - коммерческая деятельность для них достаточно условна. > Попробуйте создать ИТ-предприятие Это предложение? ;) Или Вы делитесь своим опытом? Если предложение - спасибо, с этим государством я в эти игры не играю. Если делитесь опытом - было бы интересно послушать. > взяв кредит с целью осуществить начальное финансирование > разработки гениального софта Imho на ровном месте брать кредит нет смысла. Должна быть по крайней мере интересная бизнес-идея. Если она есть, то опять же кредит брать смысла нет, - imho проще и дешевле попросить денег у друзей или сделать разработчиков партнерами. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 15:03 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 > Попробуйте создать ИТ-предприятие Это предложение? ;) Или Вы делитесь своим опытом? Если предложение - спасибо, с этим государством я в эти игры не играю. Если делитесь опытом - было бы интересно послушать. Imho на ровном месте брать кредит нет смысла. Должна быть по крайней мере интересная бизнес-идея. Если она есть, то опять же кредит брать смысла нет, - imho проще и дешевле попросить денег у друзей или сделать разработчиков партнерами. ;)Нет, это суждение опытного главбуха, высказанное в ответ на вопрос о том, что ждет предположительно хорошую бизнес-идею при попытках легально взять кредит (ну предположим, что нет друзей :) да и кредит отдавать - все не то же самое, что продавать за венчурное финансирование долю в этой самой идее) и финансировать с него разработку и продвижение продукта. Более того, если не брать кредит, а создать предприятие, набрать сотрудников и работать забесплатно (ну хотя бы тратить уставной фонд), налог тоже могут предложить заплатить "а вот как у такой же компании". Выяснять, так ли это на практике и получится, я не пытался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 15:12 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> предположительно хорошую бизнес-идею ;) Т. е. бизнес-план уже нарисован? > создать предприятие, набрать сотрудников и работать забесплатно Поправьте меня, если я ошибаюсь, но по-моему законодательно понятие "забесплатно" не определено. Более того, руководитель предприятия несет персональную ответственность за невыплату заработной платы. > налог тоже могут предложить заплатить Не "могут предложить", а заставят заплатить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 15:30 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> предположительно хорошую бизнес-идею ;) Т. е. бизнес-план уже нарисован?К рассматриваемому вопросу "о налогообложении ИТ-стартапов" бизнес-план отношения не имеет, до конкретики предлагаю не опускаться. И вообще, идея сама по себе, а составленный на ее основе бизнес-план - сам по себе, разве нет?.. guest_20040621> налог тоже могут предложить заплатить Не "могут предложить", а заставят заплатить.Есть печальный опыт? Будет лишним подтверждением вышеприведенному суждению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 15:43 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> К рассматриваемому вопросу "о налогообложении ИТ-стартапов" Хорошо, что Вы тему сформулировали, - я никак понять не мог, о чем, собственно, речь. ;) Вы это в контексте рекламируемых налоговых преференций для IT-лавчонок? > до конкретики предлагаю не опускаться ОК, не будем. Вдруг невзначай пара интересных мыслей проскочит, местная публика - народ ушлый, враз уволокут и реализуют. ;) Я вот думаю, автор треда о каталоге ПО по-хорошему проставиться должен. ;) Иначе что же получается - две страницы текста нафигачили напрасно? ;) Хотя на самом деле интересно было бы опустить до конкретики. Imho идеальный вариант для стартапа - документооборот. Imho не слишком сложная и не слишком объемная задача в сравнении со стоимостью рабочего места. ;) Что-нибудь скажете по этому поводу? > И вообще, идея сама по себе, а составленный на ее основе > бизнес-план - сам по себе, разве нет?.. Это как посмотреть. Если рассматривать бизнес-план как средство для получения кредита - видимо, да. Если как план - imho скорее нет. ;) > Есть печальный опыт? Почему "печальный"? ;) Здесь как бы не о печали речь. Есть правила игры, которые нужно либо принимать, либо не участвовать в игре совсем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 17:16 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> К рассматриваемому вопросу "о налогообложении ИТ-стартапов" Хорошо, что Вы тему сформулировали, - я никак понять не мог, о чем, собственно, речь. ;) Вы это в контексте рекламируемых налоговых преференций для IT-лавчонок?Фу... хотя Вы дали повод внимательнее отнестись к новостям на эту тему. guest_20040621> до конкретики предлагаю не опускаться ОК, не будем. Вдруг невзначай пара интересных мыслей проскочит, местная публика - народ ушлый, враз уволокут и реализуют. ;) Я вот думаю, автор треда о каталоге ПО по-хорошему проставиться должен. ;) Иначе что же получается - две страницы текста нафигачили напрасно? ;)Да лишь бы в депрессию не впал. Ну, а местная публика более озабочена тонкостями эксплуатации и использования РСУБД. guest_20040621Хотя на самом деле интересно было бы опустить до конкретики. Imho идеальный вариант для стартапа - документооборот. Imho не слишком сложная и не слишком объемная задача в сравнении со стоимостью рабочего места. ;) Что-нибудь скажете по этому поводу?Вы хорошо пошутили, ибо документооборот существенно сложнее учета как такового, а если взять проблемы реализации, то может оказаться и сложнее ERP, что бы там под этой аббревиатурой не понимали. В стоимости рабочих мест наблюдаю неслабый перекос (если отвлечься от стоимости СУБД, которая для конечного потребителя должна бы концептуально входить в стоимость системы). Думаю, это потому что спрос не сформирован. Стартапы "местного пошива" могу вспомнить с ходу такие: - документооборот с веб-интерфейсом (не вполне стартап в плане создания продукта с нуля, т.к. вначале слабали или украли CMS) - не развивается - система управления поручениями, опять-таки с веб-интерфейсом - расширяет продажи, слабенький документооборот дописали, продукт развивается, но имхо можно и побыстрее - недавно промелькнувшая новость про огроменнные вливания в контору, пишущую какие-то невразумительные приблуды для интеграции известных ERP и CRM-систем с майкрософт офисом - куча предложений раскрутить сайт и т.д. от более-менее прилично оформленных фирмочек (вот вам бизнес без больших начальных вложений), но по сути страдающих непрофессионализмом (иногда очень сильно страдающих) - фирма - внедренец линукс-решений (опять без вложений) - надеюсь, таки почила в бозе - ушедших с рынка российских систем ERP могу насчитать несколько штук, уходят они обычно в течение 2-3 лет, некоторые дольше - аргумент ли это в пользу слабой идеи? кто его знает Думаю, документооборот (+управление поручениями, с тонким клиентом) - еще не до конца освоенная ниша. Тут Вы в точку попали. Другое дело, что глупо догонять, а догонять придется. guest_20040621> И вообще, идея сама по себе, а составленный на ее основе > бизнес-план - сам по себе, разве нет?.. Это как посмотреть. Если рассматривать бизнес-план как средство для получения кредита - видимо, да. Если как план - imho скорее нет. ;)Согласен. Только фискальным органам плевать на качество бизнес-плана и идеи, послужившей для него отправной точкой. Вообще здравый смысл прослеживается с трудом - зачем резать курицу, несущую золотые яйцы? guest_20040621Есть правила игры, которые нужно либо принимать, либо не участвовать в игре совсем.Хм... у них есть неформальные правила но это уже жестокий оффтоп ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 17:38 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Фу... хотя Вы дали повод внимательнее отнестись к новостям на эту тему. Я нечаянно. :( На самом деле именно "фу...". > документооборот существенно сложнее учета как такового Простите мне мою тупость, не поясните - чем сложнее? > Стартапы "местного пошива" могу вспомнить с ходу такие: Ух, сколько новых слов я сегодня узнал. ;) Оконтурите, пожалуйста, "местный пошив". Наверное, что-то из того, о чем Вы рассказали, я видел в новостях, но, видимо, читалось это не очень внимательно, поэтому мне сложно связать события с конкретными участниками рынка. Если честно, я не слишком хорошо представляю себе отечественный рынок коммерческого ПО. Участников - примерно на уровне РБКашного топ-100, собственно ПО - весьма отрывочно. :( > Другое дело, что глупо догонять, а догонять придется. Imho не обязательно догонять. Есть куча боковых трендов. ;) Вы сказали о поручениях, можно добавить и другие простые фичи, которые легко вписываются в контекст. > Вообще здравый смысл прослеживается с трудом Предлагаю не обсуждать ни этот тезис, ни подобные. Сэкономим кучу времени при заранее известном итоге. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 18:19 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> документооборот существенно сложнее учета как такового Простите мне мою тупость, не поясните - чем сложнее?Тупость непростительна. Она имманентна индивидууму и никак не коррелирует ни с его кармой, ни с усилиями, прилагаемыми в области профессиональной самореализации. Право же прощать даруется одновременно с правом судить, я на сие не претендую, ибо ответить придется ;) Касательно сложнее у меня есть мера для оценки Проект системы документооборота, коим я имел удовольствие порулить на этапе реализации прототипа, имел вчетверо больше строк кода и примерно во столько же раз больше таблиц, чем реализованная ранее система учета, функциональный аналог которой должен был по плану войти составной частью в интегрированную систему. Вчетверо большим количеством элементов я обосновываю необходимость качественного скачка в сложности системы :) Не особенно научно, но тем не менее. guest_20040621Ух, сколько новых слов я сегодня узнал. ;) Оконтурите, пожалуйста, "местный пошив".Ну, мне показалось. что к российским вновь созданным ИТ-компаниям смешно применять западное слово стартап , я и позволил себе внести толику юмора, аппелируя к эпохе кооперативов (о которой Вы, наверное, имеете куда более подробное представление :( ) guest_20040621> Другое дело, что глупо догонять, а догонять придется. Imho не обязательно догонять. Есть куча боковых трендов. ;) Вы сказали о поручениях, можно добавить и другие простые фичи, которые легко вписываются в контекст. Другое дело, нужны ли они тупому юзеру . Сразу могу назвать такую фичу, как хороший интегрированный почтовый клиент - уж как только не извращаются разработчики, а дзен не наблюдается ни в случае самостоятельной реализации, ни в случае привинчивания на соплях мс аутлука . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 18:34 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Вчетверо большим количеством элементов я обосновываю > необходимость качественного скачка в сложности системы Расскажите, пожалуйста, что именно было реализовано в документообороте. Понятно, что для учетной программулины нет необходимости полнотекстового поиска, полноценной мультиязычности, процессов и пр., - но мне их реализация не кажется качественным скачком, а вчетверо больший объем работы представляется завышенным. Например, потому, что наиболее трудоемкой задачей я полагаю разделение доступа (кстати, до сих пор не видел ни одной реализации на приемлемом уровне, несмотря на то, что моделей - вагон и маленькая тележка), который, вообще говоря, нужен в обоих случаях. Хотя, конечно, заочно о продукте говорить невозможно. Может, дело не в документообороте? ;) Может, это учетная программа была слишком простой? ;) > Другое дело, нужны ли они тупому юзеру. Это imho неправильная постановка вопроса. Юзеру комфортно, если его вообще все оставят в покое и не будут считать внешний трафик. ;) > хороший интегрированный почтовый клиент Хм... а почему это фича? Я считал это стандартной тулзой... Если Вы говорите о коммуникации, фичей можно было бы считать, например, IM + mail + мобильные сервисы (с обычным и мобильным интерфейсом). Только imho есть более простые пути расширения функционала. > дзен не наблюдается А должен бы? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 22:08 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Вчетверо большим количеством элементов я обосновываю > необходимость качественного скачка в сложности системы Расскажите, пожалуйста, что именно было реализовано в документообороте. Понятно, что для учетной программулины нет необходимости полнотекстового поиска, полноценной мультиязычности, процессов и пр., - но мне их реализация не кажется качественным скачком, а вчетверо больший объем работы представляется завышенным. Например, потому, что наиболее трудоемкой задачей я полагаю разделение доступа (кстати, до сих пор не видел ни одной реализации на приемлемом уровне, несмотря на то, что моделей - вагон и маленькая тележка), который, вообще говоря, нужен в обоих случаях. Хотя, конечно, заочно о продукте говорить невозможно. Может, дело не в документообороте? ;) Может, это учетная программа была слишком простой? ;)Что есть приемлемый уровень разделения доступа к документам? Права на чтение, изменение, выдачу прав - для пользователей и групп пользователей - вроде как этого хватает. Набор обязанностей по отношению к документу, само собой - для пользователей и групп. В учетной системе доступ к функционалу и различным областям данных рациональнее предоставлять через роли, в системе документооборота это я считаю излишним. Учетная программа была достаточно простой - по функциональности а-ля Гепард, Фрегат, БЭСТ-4 и иже с ними. Согласен, что если ее двинуть в сторону планирования и прогнозирования, сложность существенно повысится. Но муторности проектирования и реализации GUI системы ECM все равно не будет в этом проекте. Документооборот тоже достаточно простой - примерно как в NauDoc. Что-то лучше, что-то хуже. Управление поручениями лучше. В общем-то систему документооборота проектировать и реализовывать - более спокойное дело, чем систему учета. В ней нет отражения финансовых взаиморасчетов и т.д. и т.п. :) guest_20040621> Другое дело, нужны ли они тупому юзеру. Это imho неправильная постановка вопроса. Юзеру комфортно, если его вообще все оставят в покое и не будут считать внешний трафик. ;) И еще надо кофе и сахар за счет фирмы. guest_20040621> хороший интегрированный почтовый клиент Хм... а почему это фича? Я считал это стандартной тулзой...Увы. guest_20040621Если Вы говорите о коммуникации, фичей можно было бы считать, например, IM + mail + мобильные сервисы (с обычным и мобильным интерфейсом). Только imho есть более простые пути расширения функционала. IM с почтой гугл скрещивает - имхо безуспешно. Разное поведение юзера - почту он смотрит регулярно, а в ИМ если сидит, так постоянно. ИМ мы у себя сделали, но с популярными протоколами ИМ работать не пробовали, ресурсов на такие рюшечки нет, и смысла особо нет. ИМ в составе интегрированной системы, похоже, еще не востребован. Мобильные сервисы - хороший повод махать флагом, многие geekнутые потребители ведутся на это. Спрашивают - а синхронизация с пальмой у вас есть?.. guest_20040621> дзен не наблюдается А должен бы? ;)Как сэйлзов послушать, так пора бы уж. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2006, 22:34 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Что есть приемлемый уровень разделения доступа к документам? Imho корректно реализованная модель. > Права на чтение, изменение, выдачу прав - для пользователей и групп > пользователей - вроде как этого хватает. В принципе, можно простейшей мандатной моделью ограничиться, - тоже будет работать. Собственно ограничение доступа - как бы не фокус; представьте, что сначала Вы спроектировали что-то учетное, потом - что-то документнооборотное, потом добавили коммуникативные сервисы, потом решили, что неплохо бы для каждого филиала иметь закрытую область, потом захотели дать доступ контрагентам к какой-то части системы, потом... еще что-нибудь нафантазировали. ;) К чему это я: мало того, что начальная модель должна быть стандартной (я не останавливаюсь на этом подробно в расчете на то, что в предыдущих обсуждениях донес свою точку зрения по этому поводу), она должна быть еще и расширяемой (вариант: начальная реализация должна быть избыточной). Просто для того, чтобы не делать одну и ту же работу несколько раз. Если, конечно, предполагается развитие продукта или линейки продуктов. ;) Если "вроде как этого хватает" и для учетной системы, и для документооборота (причем, если я правильно понял, в документообороте сделано даже проще), - мне не ясна природа четырехкратного увеличения трудоемкости реализации. > IM с почтой гугл скрещивает - имхо безуспешно. Разве? По-моему, очень даже успешно. На мой взгляд, у google вообще идеальное сочетание сервисов: IM + voice + mail. Если тестирование сервиса управления почтовыми доменами у них пройдет успешно, количество корпоративных пользователей, думаю, сильно вырастет. Впрочем, google - это отдельный разговор. Imho эталон IT компании. ;) > Мобильные сервисы - хороший повод махать флагом ;) Для отечественного корпоративного рынка Вы imho правильно оценили состояние его развития. Но это не значит, что так будет всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 01:56 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Что есть приемлемый уровень разделения доступа к документам? Imho корректно реализованная модель. Цо то ест "корректно"? Нормализовано насколько возможно?.. Или полностью отражать гипотетическую модель политики информационной безопасности?.. Или отражать возможно большее количество таких политик?.. guest_20040621> Права на чтение, изменение, выдачу прав - для пользователей и групп > пользователей - вроде как этого хватает. В принципе, можно простейшей мандатной моделью ограничиться, - тоже будет работать. Собственно ограничение доступа - как бы не фокус; представьте, что сначала Вы спроектировали что-то учетное, потом - что-то документнооборотное, потом добавили коммуникативные сервисы, потом решили, что неплохо бы для каждого филиала иметь закрытую область, потом захотели дать доступ контрагентам к какой-то части системы, потом... еще что-нибудь нафантазировали. ;) ... начальная модель ... должна быть еще и расширяемой (вариант: начальная реализация должна быть избыточной). Просто для того, чтобы не делать одну и ту же работу несколько раз. Если, конечно, предполагается развитие продукта или линейки продуктов. ;)Избыточная. Расширяемая. То и другое проверено практикой :) Про упрощенную систему в документообороте я малость некорректно выразился, она не проще, но в учетной системе мы не реализовывали возможность управлять доступом к конкретному документу, а в документообороте это есть краеугольный камень (хотя в утилитах администрирования это может быть и не прозрачно, но структура данных именно такая). guest_20040621Если "вроде как этого хватает" и для учетной системы, и для документооборота (причем, если я правильно понял, в документообороте сделано даже проще), - мне не ясна природа четырехкратного увеличения трудоемкости реализации.Это частный случай. В основном причина в том, что система учета делалась для себя, а интегрированная система - для продажи. guest_20040621... google - это отдельный разговор. Imho эталон IT компании. ;)Ай, когда я увидел рекламу в gmail, я перстал быть патриотом gmail. Хотя к тому шло. Но имидж уж не тот. guest_20040621> Мобильные сервисы - хороший повод махать флагом ;) Для отечественного корпоративного рынка Вы imho правильно оценили состояние его развития. Но это не значит, что так будет всегда."Успеем как-нибудь" Главное ведь не сервис слабать, а корректно реализовать модель предметной области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 10:11 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Цо то ест "корректно"? Да все как и для других моделей: 1. Полнота реализации. 2. Непротиворечивость. Для модели ограничения доступа: 3. Как Вы правильно заметили - соответствие общей модели информационной безопасности предприятия. 4. Возможность удобно управлять политикой доступа. Вы пробовали рулить SELinux? Это же полная ж... > В основном причина в том, что система учета делалась для себя, > а интегрированная система - для продажи. Теперь все встало на свои места. > Ай, когда я увидел рекламу в gmail, Даже такие классные парни, как google, не могут работать совсем бесплатно. > я перстал быть патриотом gmail. Можно поинтересоваться, патриотом чего Вы стали в результате? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 11:13 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Можно поинтересоваться, патриотом чего Вы стали в результате? ;)Эккаунт gmail я все так же использую, а в качестве обыкновенного почтового клиента - Thunderbird 3 альфа1 (кстати, проверю, нет ли поновее :). Evolution во многом лучше, но Evolution Data Server до ума не довели (или он плохо работает чуть ли не во всех дистрибутивах что я видел), да и под виндовс его нету , а это бывает полезно. guest_200406214. Возможность удобно управлять политикой доступа.Я периодически размышляю, не добавить ли управление по уровням секретности данных, но пока еще никто другой такое требование не озвучил (скорее всего модели с ролями в виде промежуточного слоя между юзерами и областями данных будет таки достаточно). Вот с "географическим" подходом в распределенной базе данных не работали (реализовали эрзац-решение для учетных данных (на основе типичной политики в отношении видимости тех или иных учетных данных в центре и на местах) и почти правильное решение для документооборота, в подробности последнего вдаваться смысла не вижу; если грубо, то тривиальная выдача прав филиалу, помноженная на обычную выдачу прав юзерам). guest_20040621Вы пробовали рулить SELinux? Это же полная ж... Не, не пробовал. Я так и не понял, зачем это нужно. Пробовал аутентификацию в сусе на основе виндозного домена - больше не буду пробовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 11:26 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> не добавить ли управление по уровням секретности данных Данные шифруются? Есть ограничение доступа на уровне СУБД? > Вот с "географическим" подходом в распределенной базе данных не работали В смысле "центр" - "филиалы"? Кстати, интересная задача. > тривиальная выдача прав филиалу, помноженная на обычную выдачу прав юзерам Тоже вариант. В идеале хочется иметь "систему в системе", т. е. любое (уточню: любое разумное) ;) количество "филиальных" систем в составе основной. Причем, так, чтобы "филиальные" системы были бы до определенной степени автономны (в т. ч. имели возможность запускаться на отдельном сервере с отдельным экземпляром базы данных, имели бы собственную административную часть и пр.). В принципе, решаемая задача, только хм... есть пара моментов, которые мне сильно не нравятся. ;) > зачем это нужно Классная штука, кстати. Модель ограничения доступа TE (Type-Enforcement). Все довольно просто: домены -> типы > политики доступа. Попробуйте в permissive mode - реально работать не будет, но на лог интересно посмотреть. Можно SEEdit использовать - у него свои политики, но более прозрачное управление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 15:21 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> не добавить ли управление по уровням секретности данных Данные шифруются? Есть ограничение доступа на уровне СУБД?Первое - нет; принципиально против второго. Но если действительно копать в эту сторону, то вопрос для меня видится совершенно не проработанным, и даже намеков на хорошие решения я не видел. Ведь тут и от админов закрывать надо. И так далее. guest_20040621 чтобы "филиальные" системы были бы до определенной степени автономны (в т. ч. имели возможность запускаться на отдельном сервере с отдельным экземпляром базы данных, имели бы собственную административную часть и пр.)Так и есть. В конкретном случае решили так - таблица юзеров реплицируется (в принципе, можно иметь ее в филиалах частично), а права доступа - нет. Выдаются в каждом филиале специально. На документы же выдаются еще и права филиалов - грубо говоря, куда отослать и где разрешать редактировать. guest_20040621> зачем это нужно Классная штука, кстати. Модель ограничения доступа TE (Type-Enforcement). Все довольно просто: домены -> типы > политики доступа. Попробуйте в permissive mode - реально работать не будет, но на лог интересно посмотреть. Можно SEEdit использовать - у него свои политики, но более прозрачное управление.На досуге посмотрю. В практике использовал только AD, т.е. из противоположного лагеря, но до чего же недоделанная вещь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 15:35 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Вижу, неясно написал - права юзеров на документ приезжают в филиал вместе с документом, т.е. можно в центре указать в какие филиалы отсылать и кому там что разрешать делать. Конечно, под конкретную организацию можно это видоизменить, но пока таких запросов не поступило. Наш клиент - СМБ - не особо взыкателен в данном вопросе, опыта не имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 15:45 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621В идеале хочется иметь "систему в системе", т. е. любое (уточню: любое разумное) ;) количество "филиальных" систем в составе основной. Причем, так, чтобы "филиальные" системы были бы до определенной степени автономны (в т. ч. имели возможность запускаться на отдельном сервере с отдельным экземпляром базы данных, имели бы собственную административную часть и пр.). В принципе, решаемая задача, только хм... есть пара моментов, которые мне сильно не нравятся. ;) Какие именно, можете уточнить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 16:07 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Первое - нет; принципиально против второго. Тогда в чем смысл управления уровнями секретности? - dba все видит. Почему принципиально против ограничений на уровне пользователей БД? > Ведь тут и от админов закрывать надо. И так далее. Может, так: уровень доступа сопоставлен пользователю БД, которому также сопоставлен некий ключ? Никто, кстати, не мешает иметь свой ключ для приватных данных реальному пользователю. > На документы же выдаются еще и права филиалов - грубо говоря, > куда отослать и где разрешать редактировать. Если "где разрешать редактировать" - не уникально, то я не очень понимаю, как Вы разгребаете версионность и как расставляете приоритеты изменений. Если уникально, почему не использовать традиционное понятие владельца? > На досуге посмотрю. Я плохо рассказал; нужно было сразу уточнить. Домены в SELinux - это не обычные домены, это такая абстракция контекста для процессов. ;) Ну, вот так неудачно назвали. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 16:19 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Тогда в чем смысл управления уровнями секретности? - dba все видит.Проблема всевидящего ДБА - это одна проблема, а проблема назначения информации некоего уровня секретности - другая. На практике я их делю и пока первую не пытаюсь решить. Я все говорил применительно к правам доступа пользователей - например, документ имеет гриф ДСП и к нему нет доступа у юзера Гест, пофиг что это документ относится, например, к ОбластиОбщихЗнаний и у Геста есть доступ к этому типу документов. guest_20040621Почему принципиально против ограничений на уровне пользователей БД?Просто потому что предпочитаю аутентификацию средствами разрабатываемой системы, а не средствами ОС. Надежнее? Кто его знает. Мне так удобнее по жизни. > Ведь тут и от админов закрывать надо. И так далее. guest_20040621Может, так: уровень доступа сопоставлен пользователю БД, которому также сопоставлен некий ключ?Логически верно и хорошо. Как реализовать - без понятия. guest_20040621Никто, кстати, не мешает иметь свой ключ для приватных данных реальному пользователю.Никто, кроме политики администрации Другое дело, как обеспечить доступ к шифрованным данным. Не может же быть несколько ключей для расшифровки. В итоге систему довольно сложно спроектировать без дыр. guest_20040621Если "где разрешать редактировать" - не уникально, то я не очень понимаю, как Вы разгребаете версионность и как расставляете приоритеты изменений. Если уникально, почему не использовать традиционное понятие владельца?Не уникально. Апдейт-конфликты - разрешаются исходя из времени редактирования. На практике этого хватает. Недостаток - вероятность того, что на конкретном сервере время рассинхронизируется с другими. Можно запретить редактирование в других подразделениях, это тупо делается штатными средствами системы - если орг.политика такая. guest_20040621> На досуге посмотрю. Я плохо рассказал; нужно было сразу уточнить. Домены в SELinux - это не обычные домены, это такая абстракция контекста для процессов. ;) Ну, вот так неудачно назвали. ;)Ну я и не думал что это домены AD. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 16:36 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> проблема назначения информации некоего уровня секретности - другая Imho это две части одной и той же проблемы. ;) > документ имеет гриф ДСП и к нему нет доступа у юзера Гест Это понятно; доступ ограничен в рамках приложения. А имея физический доступ к бд (dba), можно видеть любые данные. Можно эту хм... неприятную возможность убрать. В принципе, я не считаю, что это приоритетная задача, но если есть возможность исключить человеческий фактор ;), я стараюсь этим пользоваться. Я не говорю, что нужно шифровать все данные, - это жуткие тормоза. Но начиная с некоторого уровня доступа - можно вполне. Кстати, пользователей с высоким уровнем доступа обычно очень мало, так что на производительности это скажется не катастрофически. ;) > предпочитаю аутентификацию средствами разрабатываемой системы, а не средствами ОС ;) И это правильно. Но одно другому ни разу не мешает. Практически все руководства по ограничению доступа начинаются с простейшего примера, связанного с ограничениями на уровне объектов бд. ;) > Как реализовать - без понятия. Пара ключей: один пользователь - система (условно), другой пользователь - пользователь базы данных (фактически - уровень доступа). > Не может же быть несколько ключей для расшифровки Конечно, не может. ;) > В итоге систему довольно сложно спроектировать без дыр. Да нет, абсолютно реально. Только ресурсов она будет есть... как хороший, большой паровоз. ;)) Впрочем, сервера дешевеют на глазах. ;) > Можно запретить редактирование в других подразделениях Я бы так и сделал. Нужны изменения - пишешь исправления и отправляешь автору документа, пусть он разбирается. Для коллективной работы я бы завел отдельный тип документа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2006, 19:37 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> проблема назначения информации некоего уровня секретности - другая Imho это две части одной и той же проблемы. ;) Об этом мы тоже никому не расскажем. Это как эзотеричность знаний о конструкции замков ;) guest_20040621Практически все руководства по ограничению доступа начинаются с простейшего примера, связанного с ограничениями на уровне объектов бд. ;)Ай, эти простейшие примеры... Ну зачем зависеть от ДБА. Другое дело, что если оправдано усилить систему защиты от НСД (понижая вероятность успешного осуществления попыток оного), то это надо сделать. guest_20040621> Как реализовать - без понятия.Ну в общем-то мало-мало подумавши вариант не один появляется, да. guest_20040621> В итоге систему довольно сложно спроектировать без дыр. Да нет, абсолютно реально. Только ресурсов она будет есть... как хороший, большой паровоз. ;)) Впрочем, сервера дешевеют на глазах. ;)В частном случае тонкого клиента можно шифрование выполнять на нем (и доступа ДБА к администрированию рабочих станций не давать :). guest_20040621Для коллективной работы я бы завел отдельный тип документа.Дельная мысль. На практике документ не просто пишется толпой (для этого и вики сойдет), а ходит по маршруту. И редактируется на каждой стадии кем-то одним (обычно), так что "многопользовательскость" здесь даже и излишня как-бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2006, 09:41 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Ну зачем зависеть от ДБА. Я о том же. ;) Хотя, конечно, полная независимость представляется утопией. > если оправдано усилить систему защиты от НСД Защита от НСД - комплекс мер, причем, собственно дыры в ПО - не главные дыры. ;) > На практике Кстати, еще одно простое решение: интерфейс к Subversion. Коммиты, если необходимо, можно связать с маршрутом. Так что обредактироватья можно. ;) > для этого и вики сойдет Не уверен, что удобно для этой задачи воспользоваться wiki. Впрочем, это дело вкуса. ;) Похоже, и эта тема себя исчерпала. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2006, 15:16 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Похоже, и эта тема себя исчерпала. :(Дааа, темы кончились. Пытался шо-нибудь вспомнить - нету. Спроектировали уже всё. Блин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2006, 15:33 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> темы кончились ;) Их есть. Буквально сегодня в "Коммерсанте" два интересных материала: о ЕГАИС (отдали ФНС и похоже будут переписывать) и о системе персонального учета населения МЭРТ (идентификаторов не будет; будет "стандарт процедуры отождествления данных"). С одной стороны, освоение кем-то бабла как бы нечего обсуждать, с другой - хм... задачи сами по себе достаточно интересные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2006, 22:45 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Буквально сегодня в "Коммерсанте" два интересных материала: о ЕГАИС (отдали ФНС и похоже будут переписывать) и о системе персонального учета населения МЭРТ (идентификаторов не будет; будет "стандарт процедуры отождествления данных"). С одной стороны, освоение кем-то бабла как бы нечего обсуждать, с другой - хм... задачи сами по себе достаточно интересные. Вместо уникального идентификатора будет сурогатный ключ - ДНК. Или программеры придумают новый уникальный способ идентификации человека программным способом? Смэшно. В чем интерес? Я вижу единственный - сумма бюджета. А стандарт конечно в корзину. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2006, 00:16 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Или программеры придумают новый уникальный способ > идентификации человека программным способом? Дружище, Вы абсолютно напрасно видите только технические проблемы. Дело не в программерах и не в возможностях биометрической идентификации. > В чем интерес? Чей? Разработчиков законопроекта? Разработчиков софта? Налогоплательщиков? У каждого, естественно, свой. Причем, абсолютно прозрачный. Если Вы внимательно посмотрите на задачу, то формулироваться она будет примерно так: есть некий набор обособленных информационных систем, причем, данные этих систем могут пересекаться. Вопрос: как максимально достоверно сопоставить данные всех информационных систем. Вы полагаете, решение очевидно? Было бы интересно послушать, каким Вы его видите. Hint 1: количество информационных систем не определено. Hint 2: требования к структуре и способу хранения данных информационных систем не определены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2006, 02:21 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Если Вы внимательно посмотрите на задачу, то формулироваться она будет примерно так: есть некий набор обособленных информационных систем, причем, данные этих систем могут пересекаться. Вопрос: как максимально достоверно сопоставить данные всех информационных систем. Вы полагаете, решение очевидно? Было бы интересно послушать, каким Вы его видите. Hint 1: количество информационных систем не определено. Hint 2: требования к структуре и способу хранения данных информационных систем не определены. Никак. Поэтому и говорю: самым интересным в этом деле является бюджет проекта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2006, 11:50 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Никак. В предложенной формулировке задача imho действительно решения не имеет. Однако, вполне можно себе представить некоторые ограничения к структуре и способам хранения данных, чтобы такое решение появилось. Ваш вариант таких ограничений? Ваш вариант способа решения (не с точностью до структуры данных и алгоритмов, - в общих чертах)? Это не обсуждение персонального учета населения, как может показаться. Задача интересна сама по себе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2006, 16:43 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
По обоим примерам у меня сразу перед глазами встает старая добрая Украина. guest_20040621 Буквально сегодня в "Коммерсанте" два интересных материала: о ЕГАИС (отдали ФНС и похоже будут переписывать) На Украине в 1990-х работала гос.система межбансковких расчетов. Не знаю как сейчас, а тогда платежи можно было отправить и получить в течение полутора часов, без российских извращений с "рейсами" и т.п. Тупая, надежная, грамотно сделанная система. Кроме этой системы, работали частные сети межбанковских расчетов, не мешавшие, а дополнявшие ее. Было несколько вариантов использования СКЗИ. Все очень дубово, ни разу не слышал о сбоях системы, работал сам в ней несколько лет. Сделано было в эпоху управления Нацбанком... правильно, Ю. Здесь так отчего-то не умеют. Однако там же однажды захотели сделать взаимозачет долгов предприятий. Для этого планировалось нагрузить систему межбанковских платежей примерно таких же к-вом документов о долгах, и неясно как осуществить потом взаимозачеты. Это было никому не надо. Задинамили и сдохло. ЕГАИС никому не надо (имеются в виду участники системы, не берем в расчет инициаторов и т.п.). От того, что я слышу и читаю про ЕГАИС, меня трясет. Этих, гм, разработчиков надо было отправлять сидеть на точках в тайге. И не пущать к проектированию таких систем. Ну я уже высказывался в топике про ЕГАИС. guest_20040621и о системе персонального учета населения МЭРТ (идентификаторов не будет; будет "стандарт процедуры отождествления данных").Та же Украина хотела иметь БД о всех операциях физлиц. Это хотел не банк, а ГНИ. Примитивная прикидка объема БД сразу давала вывод - ГНИ не потянет. Денег не хватит. По-моему, тоже сдохло. А реестр физлиц-плательщиков налогов делали так: организации, гед это надо делать, печатают на бумаге, а некоторые даже покупают программы для ввода данных и печати форм (я даже такое сделал однажды), печатают и несут в ГНИ. Там сидит девочка и перебивает. Предложили принести файл - хоть бумагу сэкономили бы всем! - сказали, что нет, сказали делать как делаем. В России дури может и хватит профинансировать бюждет такой системы, но ума не хватит реализовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2006, 18:18 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Если Вы внимательно посмотрите на задачу, то формулироваться она будет примерно так: есть некий набор обособленных информационных систем, причем, данные этих систем могут пересекаться. Вопрос: как максимально достоверно сопоставить данные всех информационных систем. Вы полагаете, решение очевидно? Было бы интересно послушать, каким Вы его видите. Hint 1: количество информационных систем не определено. Hint 2: требования к структуре и способу хранения данных информационных систем не определены. Главное, чтобы нам (налогоплательщикам) не продали для этого BizTalk. Боже, если ты есть, сделай так, чтобы нам (налогоплательщикам) не продали для этого BizTalk. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2006, 18:21 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Никак. В предложенной формулировке задача imho действительно решения не имеет. Однако, вполне можно себе представить некоторые ограничения к структуре и способам хранения данных, чтобы такое решение появилось. Ваш вариант таких ограничений? Ваш вариант способа решения (не с точностью до структуры данных и алгоритмов, - в общих чертах)? Это не обсуждение персонального учета населения, как может показаться. Задача интересна сама по себе. только через приведение данных в разных системах к единому формату. В общем-то так и устроена вся фискальная или статистическая отчетность. Внутри кто на что горазд, а сверху все одинаковые, в значимой части. Ограничения во внутренней структуре приведут к ограничениям использования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2006, 19:40 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
DogenГлавное, чтобы нам (налогоплательщикам) не продали для этого BizTalk. Боже, если ты есть, сделай так, чтобы нам (налогоплательщикам) не продали для этого BizTalk. Вариантов решения ровно на BizTalk или подобные ему инструменты трансформации данных. Готовьтесь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2006, 19:42 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Сделано было в эпоху управления Нацбанком... правильно, Ю. ;) Это пиар? > Здесь так отчего-то не умеют. Все просто: больше заинтересованных сторон. Нет баланса противовесов. ;) > иметь БД о всех операциях физлиц. Это хотел не банк, а ГНИ. Примитивная прикидка > объема БД сразу давала вывод - ГНИ не потянет. Денег не хватит. Цифры не помните? В России была попытка установить контроль за расходами, - закончилась, фактически не начавшись: закопались в потоке данных. Частично возобновить практику пытаются регулярно; например, текущий хит - доступ ФНС к данным о кредитах физлиц. > В России дури может и хватит профинансировать бюждет такой системы С нефтью и, следовательно, деньгами в России сейчас все в порядке. Есть другая проблема: если создать такую систему, кто ее будет контролировать? > но ума не хватит реализовать Нет здесь ничего запредельно сложного. Та же самая задача с условно автономными системами. Фишка в том, что информационная система должна решать проблему комплексного контроля, - а это значит, что сначала придется писать кучу гейтов к существующим приложениям, а со временем и эти приложения переписывать. Imho просто некому такую задачу решать. Хороших идей - куча (в том же МЭРТе: объединение кадастра и реестра недвижимости). Их реализация - вопрос не квалификации девелоперов, а законодательства и ведомственных интересов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2006, 12:36 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> только через приведение данных в разных системах к единому формату Под форматом что имеется в виду? Структура данных? Конкретная СУБД? Спецификация? Стандарт? Что-то еще? > Ограничения во внутренней структуре приведут к ограничениям использования. Зачем структуру ограничивать? Не логичнее сформулировать правила для таких информационных систем и реализовать типовые структуры данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2006, 12:36 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Под форматом что имеется в виду? Структура данных? Конкретная СУБД? Спецификация? Стандарт? Что-то еще? > Ограничения во внутренней структуре приведут к ограничениям использования. Зачем структуру ограничивать? Не логичнее сформулировать правила для таких информационных систем и реализовать типовые структуры данных? Под форматом я имел ввиду структуру данных на выходе того, что Вы называете "гейтом". Насчет типовых структур вряд-ли получится. Кто будет делать структуры БД по принятому кем-то шаблону? Кто-то посчитает что он кривой, например. Единственный реальный, имхо, варинат - формат выходных данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2006, 15:32 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Под форматом я имел ввиду структуру данных на выходе того, > что Вы называете "гейтом". И я о том же. Важно, чтобы внутренняя структура источника позволяла поддерживать нужную структуру на выходе. Реализовать преобразование - проблема исключительно техническая. Причем, единственное требование - однозначность преобразования; если источник используется только для чтения - однозначность преобразования в одном направлении. > Кто будет делать структуры БД по принятому кем-то шаблону? Что значит "кем-то"? Почему официальные структуры не могут иметь собственные стандарты для баз данных, которые сами же и используют? Шаблоны могут преследовать две цели: 1. подсказка готового решения разработчику, 2. определение минимума количества информации для конкретной задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2006, 18:35 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621Почему официальные структуры не могут иметь собственные стандарты для баз данных, которые сами же и используют? Шаблоны могут преследовать две цели: 1. подсказка готового решения разработчику, 2. определение минимума количества информации для конкретной задачи. Официальные могут, согласен. Я бы сказал обязаны, чтобы исключить многообразие стандартов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2006, 19:40 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Вопрос к guest_20040621 и к Dogen: Возвращаясь к мандатной защите, не подскажете, как реализовать такое требование к безопасности данных: Имеется централизованное хранилище информации и клиенты, подключенные к нему. Каждый клиент в этом хранилище имеет свой собственный сегмент данных. Для простоты обозначим следующее: Таблица - реализация Бизнес сущности Запись - реализация экземпляра Бизнес Сущности Столбец - реализация определенного атрибута Бизнес Сущности Пользователь - владелец сегмента данных Так вот каждый клиент должен иметь возможность для каждой Таблицы определить одну (или не сколько) Политик Доступа к Данным. Каждая Политика содержит такие параметры: 1. Таблица, к которой применяется Политика 2. Необязательный дополнительный фильтр Записей (я написал дополнительный, потому что по умолчанию работает фильтр: Пользователь=Владелец) 3. Сведения об открытых (общедоступных) и о закрытых (конфиденциальных) Столбцах. 4. Определить пользователей (или групп пользователей), которым разрешен доступ к открытым столбам и пользователей (или групп пользователей), которым разрешен доступ к азкрытым столбам 5. Для дополнительной конфиденциальности закрытых столбцов шифровать их собственным ключем. Это на случай, если центральное хранилище информации захватит группа лиц - так чтобы они не смогли получить доступ к конфиденциальной части Записей (основной вопрос при этом - как передавать ключи разрешенным пользователям и как, например, сделать так, чтобы этот же Пользователь смог создать другую политику, где разрешенные пользователи из первой политики НЕ имели доступа к данным второй политики) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2006, 20:49 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
1. В одной таблице информацию с разным уровнем секретности я бы не держал. Это если грубо. 2. Не переусложняйте, ибо все пароли легко доступны при использовании нагревательных приборов, будь то батарея центрального отопления либо же утюг. 3. Ключи пользователям не передаются, потому что это их сразу компрометирует. Они должны генерить ключи сами, это азбука. Вдумываться лень, т.к. ТЗ кажется писанным далекими от разработки ИС людьми. Впрочем, это все имхо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2006, 22:18 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Imho логично выделить три подзадачи: 1. метаописание структуры данных, 2. политика ограничение доступа, 3. защита данных (шифрование). Метаописание: получение сведений о статусе атрибутов, определение политики доступа. Модель ограничения доступа будет чуть шире традиционной. За основу я бы выбрал комбинацию RBAC и свободного доступа. Шифрование атрибутов здесь обсуждалось. Приватные ключи можно хранить на дополнительно защищенном девайсе (например, шифрованном разделе или удаленном хосте). Imho постановка задачи сыровата. Основная проблема - невнятная логическая модель (абсолютно непонятно, почему возможно существование нескольких политик?). P.S. Если это open source проект - с удовольствием расскажу подробнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 11:22 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Как-то не верится что "Бизнес Сущности" будут только храниться в таблицах. "Бизнес Логика" подразумевается?.. Доступ процедур к "Бизнес Сущностям"?.. Как с конкретной постановкой задачи вяжется то, что сводные данные могут на практике иметь более другой уровень секретности, чем данные, использованные для построения отчета?.. =============================================================================== Отвечать без смысла на это письмо. Сообщение направлено вам роботом доски объявлений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 11:41 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
@Dogen: Я согласен, что ключ пользователя-владельца генерится им самим, как быть с теми, кому он дал права на чтение шифрованных полей? Им же их как-то расшифровать надобно... @guest_20040621 огромное спасибо за RBAC - буду изучать документ Открою чуть подробнее и на более абстрактном уровне чего надо: Планируется открытие электронной информационной биржи (Хранилища Информации - ХИ). Товар биржи - информация - ее продают, покупают. ХИ находится на стороне компании-владельца проекта). Каждый клиент биржи должен обладать следующими возможностями: 1. Заносить свою информацию, при этом он должен быть гарантированно защищен от того, что в случае физического доступа к ХИ злоумышленники получат болт. Предполагаемое решение: 1.1. внедрить на стороне ХИ шифрование данных - либо на уровне файловой системы, либо на уровне сервера, либо на уровне таблиц 1.2. данные клиента шифруются своим собственным ключем - на случай, если под утюгом сотрудник компании-владельца проекта расколится на предмет ключа шифрования ХИ, тогда пускай едут к клиенту - другим утюгом работать (уже его проблемы) 2. Создавать публикации своей информации - КТО, на КАКИХ УСЛОВИЯХ и НА КАКОЙ СРОК имеет доступ к информации клиента. При этом клиент должен иметь также возможность для того, чтобы заинтересовать других клиентов, открыть общедоступную часть публикации для просмотра. При этом система должна автоматически: 2.1. определять, что условия наступили 2.2. определять кому предоставить доступ в связи с 2.1 2.3. наконец этот доступ предоставить 2.4. при наступлении момента окончания подписки - в доступе отказать 3. Подписываться на публикации, созданные другими клиентами. При этом система переводит с баланса клиента-подписчика на баланс клиента-публикатора соответствующуюю цифру (если публикация платная - могут быть и бесплатные)и дает доступ P.S. не стоит ли открыть другой топик для продолжения темы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 13:54 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Stas Tristan@Dogen: Я согласен, что ключ пользователя-владельца генерится им самим, как быть с теми, кому он дал права на чтение шифрованных полей? Им же их как-то расшифровать надобно...Ключ для расшифровки конкретных данных может быть предоставлен пользователям, будучи зашифрованным их открытым ключом. Это должен явно делать тот, кто выдает доступ к этим данным. Например. Можно, наверное, по-разному тут подойти. Общий подход, вероятно, осветит quest_... Stas Tristanспасибо за RBAC"тут я вдруг узнал что всю жизнь говорю прозой" Stas Tristan1. Заносить свою информацию, при этом он должен быть гарантированно защищен от того, что в случае физического доступа к ХИ злоумышленники получат болт. Гарантированная защита информации достигается путем ограничения физического доступа. Есть физический доступ к носителям или каналам передачи данных - считайте защиту скомпрометированной. Если говорить о том, что надо еще время на взлом и т.д. и т.п. - это уже даже не вопросы оперативно-розыскной деятельности, а вопросы построения полукриминальной стратегии работы Вашей гипотетической компании. Вы какую-то башню из слоновой кости строите, и сами в такой же сидите. Как этот проект будет в наших реалиях существовать?.. И что там продавать?.. Stas Tristan2. Создавать публикации своей информации - КТО, на КАКИХ УСЛОВИЯХ и НА КАКОЙ СРОКПроблемы с логикой - что значит срок?? Однажды открыл - считай, навсегда доступно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 14:24 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Stas Tristan2. Создавать публикации своей информации - КТО, на КАКИХ УСЛОВИЯХ и НА КАКОЙ СРОК Проблемы с логикой - что значит срок?? Однажды открыл - считай, навсегда доступно. Подписался, например, на месяц - значит ровно месяц имеешь доступ к информации и к ее обновлениям, закончился месяц - доступ имеешь только к той информации, что вышла в пределах этого месяца, к обновлениям доступ закрыт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 14:37 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Stas Tristan Stas Tristan2. Создавать публикации своей информации - КТО, на КАКИХ УСЛОВИЯХ и НА КАКОЙ СРОК Проблемы с логикой - что значит срок?? Однажды открыл - считай, навсегда доступно. Подписался, например, на месяц - значит ровно месяц имеешь доступ к информации и к ее обновлениям, закончился месяц - доступ имеешь только к той информации, что вышла в пределах этого месяца, к обновлениям доступ закрытЭто другое дело. Но к отдельным порциям - обновлениям - применимо то, что я сказал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 14:38 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Это должен явно делать тот, кто выдает доступ к этим данным. Я бы тоже так сделал. Причем, ничто не мешает генерировать ключ с ограниченным временем действия. > физический доступ к носителям Можно тоже шифровать. Ценой потери ~5 - 20 процентов производительности. > каналам передачи данных Как вариант - vpn. Только вот вопрос: что таким образом защищается? Есть смысл городить огород? > Как этот проект будет в наших реалиях существовать? Мне тоже не слишком понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 15:07 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Господа, если можно в моем посте выше, где я абстрактно описал основные положения необходимой защиты, отметить пункты, за реализацию которых вы бы даже не взялись, в идеале - с обоснованием. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 15:22 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Ничего сверхсложного в описанном нет. Но за проект я бы не взялся: Вы жестко определили imho далеко не очевидные допущения: все поставщики данных готовы их разместить на Вашем сервере строго определенным Вами образом; для любого поставщика данных приемлем предложенный Вами способ доступа, предложенная Вами тарификация и предложенная Вами защита. Полагаю, это слишком оптимистичный подход. Кстати, наиболее потенциально интересную часть описанного проекта - агрегирование данных нескольких источников - Вы даже не упомянули. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 15:58 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 все поставщики данных готовы их разместить на Вашем сервере строго определенным Вами образом; для любого поставщика данных приемлем предложенный Вами способ доступа Это гарантируется guest_20040621 для любого поставщика данных приемлема предложенная Вами тарификация и предложенная Вами защита. С тарификацией проблем тоже не будет, защита будет приемлема в том случае, если будут выполняться требования описанные выше, а именно гарантия неприкосновенности данных клиентов даже владельцами проекта ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 16:14 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Stas Tristan С тарификацией проблем тоже не будет, защита будет приемлема в том случае, если будут выполняться требования описанные выше, а именно гарантия неприкосновенности данных клиентов даже владельцами проекта На фига козе баян? Сделайте аукцион информационных лотов, ведь все равно информацию будут покупать, а кто покупает кота в мешке? - хоть название и аннотация блока неких закрытых данных должны иметься в открытом виде. Ну так и не храните данные у себя! Просто выступите посредником. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 16:54 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> С тарификацией проблем тоже не будет Кто-то захочет продавать по-килобайтно, кто-то по-документно, кто-то по времени доступа. У каждого владельца данных есть свои бизнес-процессы. Вряд ли он их будет менять при никем не гарантированном результате. Впрочем, если Вы в этом уверены, - никаких проблем. Просто считаю нужным обратить на это внимание. И еще: г-н Dogen правильно пишет: "Ну так и не храните данные у себя! Просто выступите посредником." Для части данных это imho наиболее логичное решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 19:44 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1545088]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
182ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
157ms |
get tp. blocked users: |
2ms |
| others: | 233ms |
| total: | 630ms |

| 0 / 0 |
