а может ли РНР «рожать» системные группы, и «плодить» туда ю @ DeForum.ru

<BLOCKQUOTE>quote:<HR>Автор Сообщения Original Demon:
 [img]images/smiles/icon_confused.gif[/img] можно же пальцы сломать, выписывая причастные обороты.<HR></BLOCKQUOTE>

Осваиваем слепой десятипальцевый метод печати -- и жизнь переменится. [img]images/smiles/icon_smile.gif[/img]

Crazy
Собственно, путь очевиден: чтобы уименьшить произведение мы должны уменьшить по крайней мере один из множителей. Можно оба
то есть отказаться от определённого количества обьектов ? групп ? юзеров ?

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

К примеру, если у нас есть 300 пользователей, объединенных в 20 групп, и 100,000 объектов, которые мы разбили на 1000 групп доступа, то получаем 20,000 отметок о правах. Уже вполне приемлемое значение
не понял, как это ты получил 1,000 групп доступа ?

Дальше можно не продолжать. Пользователь вообще не имеет аккаунта и не входит вообще ни в какую группу

Пользователь, владеющий файлами веб-сервера
ша ! [img]images/smiles/icon_smile.gif[/img] это моя ветка, тут не сраться ! [img]images/smiles/icon_smile.gif[/img]

Именно "специально непонимаю". Потому что благодаря "упрощенной трактовке" из описания исчезла разница между пользователем UserAgent'а и владельцем файлов.
оооо …. наконец то !
изначально, мне требовалось именно это !
располочковываю !

сервер. на нём мой аккаунт (может даже и только мой). я там пользователь. по имени Intelligent. и я знаю свой пароль на ФТР [img]images/smiles/icon_smile.gif[/img]

дальше, я создаю структуру базы данных. которая содержит уже моих пользователей. так ? всякие модераторы, админы … у меня на сайте в смысле.

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

а ! если это файлы, которые идентифицируют права доступа определённого пользователя, (админа какого-то) в определённую дирректорию (нет ! не в дирректорию ! а право на изменения какой то записи в БД, которой соответствует эта дирректория), то эти файлы уже не мои, но именно этого конкретного пользователя ! о !

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

видимо я в прошлый раз не совсем толково обьяснил суть этой администрации портала. сорри.

теперь всё же к вопросу [img]images/smiles/icon_smile.gif[/img]
а вопрос был задан очень конкретно, не смотря на то что его все проигнорировали [img]images/smiles/icon_smile.gif[/img]
а по поводу толковости разьяснения этой структуры, то обладая 10палечным слепым как крот методом писанины, я растолковывал через асю эту тему мужику столь же быстро печатающему в течении 5-ти часов.
так что не обижайтесь, как быстро печатающие так и быстро читающие. это действительно сложно обьяснить без наглядных примеров и определённой жестикуляции.

было написано 27 Апреля 2002 05:08 · профиль · сайт · e-mail · сообщение · правка · цитировать · IP ·

так вот в чём вопрос то - будет ли такая система описания распределения прав доступа лучше по параметрам :
1) скорости определения прав на конкретный обьект
2) физически занятое место на сервере
3) скорость изменения определения прав юзера на все обьекты
4) геморрой

<BLOCKQUOTE>quote:<HR>Автор Сообщения Intelligent:
то есть отказаться от определённого количества обьектов ? групп ? юзеров ?<HR></BLOCKQUOTE>

Признаться, мне непонятна цель этого вопроса. Высказывание было пояснено ниже, и, как я вижу, ты это пояснение прочел. [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE>quote:<HR>Самый очевидный путь -- обобщение. Т.е. создаем группы пользователей (и/или группы объектов) и уже их объединяем в матрицу доступа
я уже об этом думал. теряется гибкость, и при серьёзных обобщениях, теряется смысл в неограниченной вложенности обьектов тоже. вообщем - не катит.<HR></BLOCKQUOTE>

Опять же: ниже было сказано, что делать, если гибкости не хватает.

<BLOCKQUOTE>quote:<HR>
К примеру, если у нас есть 300 пользователей, объединенных в 20 групп, и 100,000 объектов, которые мы разбили на 1000 групп доступа, то получаем 20,000 отметок о правах. Уже вполне приемлемое значение
не понял, как это ты получил 1,000 групп доступа ?<HR></BLOCKQUOTE>

Я это получил обобщением. Методика обобщения зависит от предметной области. Рассмотрим пример разбивки. Пусть у нас есть контора о пяти департаментах. Обычно в рамках департамента все имеют доступ ко всем документам. Доступ к документам других департаментов регламентируется отдельно. Тогда мы можем разделить все документы на 5 групп по принадлежности к департаментам.

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

Кстати, если не вводить обобщение совсем, то ты сталкиваешься с другой стандартной проблемой. Пусть у нас ОГРОМНЫЙ диск и быстрые средства проверки доступа. Матрица 100,000x300 нас устраивает. Но вот приходит новый пользователь и мы должны назначить ему права доступа. Внимание, вопрос: как ты представляешь себе процесс ИНДИВИДУАЛЬНОГО назначения прав доступа нового пользователя к каждому из 100,000 документов? [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE>quote:<HR>
ша ! [img]images/smiles/icon_smile.gif[/img] это моя ветка, тут не сраться ! [img]images/smiles/icon_smile.gif[/img]
<HR></BLOCKQUOTE>

"Надеюсь, благородное собрание не будет возражать, если я закурю?" (c) поручик Ржевский

Кстати, если не вводить обобщение совсем, то ты сталкиваешься с другой стандартной проблемой. Пусть у нас ОГРОМНЫЙ диск и быстрые средства проверки доступа. Матрица 100,000x300 нас устраивает. Но вот приходит новый пользователь и мы должны назначить ему права доступа. Внимание, вопрос: как ты представляешь себе процесс ИНДИВИДУАЛЬНОГО назначения прав доступа нового пользователя к каждому из 100,000 документов?

ещё 100,000 записей в таблицу … видимо …
да и работает это уже так …
только вот момент, я прописываю только то, куда можно, а это обычно меньше чем то, куда нельзя , или все обьекты.
поэтому, если ему "можно" что то делать в 20% от всей инфы, то я пропишу 20,000 записей.

"Надеюсь, благородное собрание не будет возражать, если я закурю?" (c) поручик Ржевский
а давай [img]images/smiles/icon_smile.gif[/img] я тоже [img]images/smiles/icon_smile.gif[/img] <IMG SRC="smoke.gif" border="0">

[ 27 Апреля 2002: Исправлено Intelligent ]

а как ты планируешь вводить обобщения програмным методом ?
если изначально всё продумать, и прописать - то куда не шло. а если потом, что бы скрипт обобщял ?
это не сложновато получится ? сам алгоритм обобщения в смысле ?

Я конечно дико извЯнЯюсЯ.…. но это все разговор слепого с глухими.

Задан вопрос: Символические линки это как, класcно ?
Получен ответ: Если 2 * 2 то получиться 4, я правильно говорю товарищи... но вот если полученое поделить на 2 то получиться 3.… и опять вернулись к исходной задаче.….

[img]eyes.gif[/img]

<BLOCKQUOTE>quote:<HR>Автор Сообщения Intelligent:
а как ты планируешь вводить обобщения програмным методом ?<HR></BLOCKQUOTE>

Не планирую. Ну разве что ты в состоянии купить софт класса Discovery Server. [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE>quote:<HR>Автор Сообщения Intelligent:
к списку добавлю :
5) как отнесётся линух к такому количеству файлов ?
их будет больше чем обьектов. может даже больше чем обьекты*пользователи.<HR></BLOCKQUOTE>

Нормально отнесется. Тем более, что в общем случае ты не ограничен выбором единственной файловой системы. [img]images/smiles/icon_smile.gif[/img]

Но, IMHO, ты слишком спешишь. Аналогия: задумав построить транспортное средство ты начинаешь подбирать можность двигателя, не опеределив, что будешь строить: автомобиль, пароход или самолет. [img]images/smiles/icon_smile.gif[/img]

буду строить zdnet.com

В таком случае начти с покупки Discovery Server. [img]images/smiles/icon_smile.gif[/img]

Crazy
[img]up.gif[/img] [img]images/smiles/icon_smile.gif[/img]
а кто это ?
и зачем его покупать ?

ну ни хрена себе ….
ок … договорились [img]images/smiles/icon_smile.gif[/img]
я вам устрою [img]images/smiles/icon_smile.gif[/img]
solutions … видите ли …
это вызов ! [img]images/smiles/icon_smile.gif[/img]

[ 29 Апреля 2002: Исправлено Intelligent ]

Если ты действительно соьбираешься делать нечто аналогичное zdnet.com, то тебе потребуется серьезный инструментарий из области управления знаниями. Вот я тебе и посоветовал один из вариантов. [img]images/smiles/icon_smile.gif[/img]

Подробности читай здесь: http://www.lotus.com/home.nsf/welcome/discoveryserver

(но я все же подозреваю, что у тебя несколько более простая задача)

ну смотри … начать я хочу с сети магазинов.
а потом - посмотрим … во что я смогу это раздуть.

ну я затрудняюсь канешна найти ту, конкретную Н-значную систему исчесления, согласно сносам десятков которой можно получить в результате - 3, но согласен с <Lamer On Line> на все 100% [img]images/smiles/icon_smile.gif[/img]

неплохо было бы получить ответ на тот … грандиозный вопрос …

к списку добавлю :
5) как отнесётся линух к такому количеству файлов ?
их будет больше чем обьектов. может даже больше чем обьекты*пользователи.

сколько места это сожрёт ? как там вообще с тысячами мелких файлов обстоит дело ?

Это точно.

Если ты хочешь делать что-то действительно серьезное, о PHP не может быть и речи. ASP+COM или JSP+EJB в зависимости от …

Я бы сказал чуть иначе:

1. Если хочется долго тянуть с заказчика деньги за разработку, то одназначно PHP.
2. Если не хочется вечно кормить нанятую проектную команду и хочется получить результат, то J2EE как бы без вариантов. [img]images/smiles/icon_smile.gif[/img]

Original Demon, если говорить о чем-то серьезном, то никакой интерпретатор это не потянет. Тем более, что СОМ относительно "тормозное" решение, и ничем не хуже пхп. Пиши исполняемый файл, длл в конце концов. [img]glasses.gif[/img] И вообще о какой сом+асп идет речь, если тут упоминался юникс? [img]amazed.gif[/img]

Шеф, согласно моим ощущениям COM куда менее тормозной, чем решения на базе Java. И если уж скорости Java хватает, то и на COM не стОит так ругаться. [img]images/smiles/icon_smile.gif[/img]

Что же до юникса, то во-первых, есть порты этой технологии под unix'а (но дорого). Во-вторых, если работа еще не начата, то не поздно и поменять платформу. [img]images/smiles/icon_smile.gif[/img]

Согласно действующим в последние 5 лет (точно), а может и больше тенденциям - всем плевать на скорость, поставим сервера помощнее.

Вся enterprise разработка делается только на Java. У меня почти все друзья на эту индустрию работают, так что я в курсе. [img]images/smiles/icon_biggrin.gif[/img]

Дело не в том, что интерпретатор не потянет, а в том, что писать на C++ или Java существенно удобнее + мы имеем все преимущества ООП.

PS (COM-решения - это и есть компиленный код)

<BLOCKQUOTE>quote:<HR>Автор Сообщения Original Demon:
Согласно действующим в последние 5 лет (точно), а может и больше тенденциям - всем плевать на скорость, поставим сервера помощнее.<HR></BLOCKQUOTE>

По большому счету эта тенденция имеет место уже лет 15-20 во всех областях, не завязанных на RealTime.

[ 29 Апреля 2002: Исправлено Crazy ]

Original Demon вместе с преимуществами ООП получаем и недостатки. Как показывает мой опыт работы (и не только мой) с ООП под веб-проекты получается проще делать модули с набором функций, нежели объекты, свойства которых в процессе создания всего проекта меняются кардинально. А еще хуже, если меняются после запуска проекта требования и функционал. [img]images/smiles/icon_sad.gif[/img] Только не надо говорить, что не правильно проектировали объекты, просто веб-проект (тем более большой) меняется очень быстро. <IMG SRC="fie.gif" border="0"> И приходится переписывать значительно больше кода, нежели если бы были простые модули. [img]weep.gif[/img]
А про ком в стравнении с пхп я имел ввиду, что все равно придется притягивать туда компилятор (скорее асп), а эта связка довольно тормозная.

[ 29 Апреля 2002: Исправлено Long ]

Знаешь как теперь такое делается? В Питере есть контора Х, так эта контора разработала софт для автоматизации написания бизнес логики. Я особо не вникал что к чему, но суть такая: имеем ранее созданые Java объекты. Рисуем направленный граф. Софт собирает продукт. Требования заказчика изменились. Перерисовываем граф. Софт собирает новую версию.

Есть еще книга, называется, кажется, "Switch-технология", автор Шалыто. У него всего 2 или 3 книги. Там как раз про то, как по графам строить алгоритмы и наоборот.

А по поводу абстрактного веб-проекта - надо рассматривать каждый конкретный случай отдельно...

<BLOCKQUOTE>quote:<HR>Автор Сообщения Long:
А про ком в стравнении с пхп я имел ввиду, что все равно придется притягивать туда компилятор (скорее асп), а эта связка довольно тормозная.<HR></BLOCKQUOTE>

[img]images/smiles/icon_confused.gif[/img] Если честно, я тебя не понял.

Проектирование, насколько я понимаю, стоит на нулевой отметке? [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE>quote

Цитата:

Рисуем направленный граф. Софт собирает продукт. Требования заказчика изменились. Перерисовываем граф. Софт собирает новую версию.

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

<BLOCKQUOTE>quote:<HR>
Есть еще книга, называется, кажется, "Switch-технология", автор Шалыто. У него всего 2 или 3 книги. Там как раз про то, как по графам строить алгоритмы и наоборот.<HR></BLOCKQUOTE>

Признаться, книг его я не читал, а потому позволю себе задать вопрос здесь: разве граф в данном случае сам по себе не является одним из представлений алгоритма?

[ 30 Апреля 2002: Исправлено Crazy ]

<BLOCKQUOTE>quote:<HR>Автор Сообщения Long:
Original Demon вместе с преимуществами ООП получаем и недостатки. Как показывает мой опыт работы (и не только мой) с ООП под веб-проекты получается проще делать модули с набором функций, нежели объекты, свойства которых в процессе создания всего проекта меняются кардинально. <HR></BLOCKQUOTE>

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

<BLOCKQUOTE>quote:<HR>Автор Сообщения Original Demon:
 [img]images/smiles/icon_confused.gif[/img] Если честно, я тебя не понял.<HR></BLOCKQUOTE>

Я, кажется, понимаю. [img]images/smiles/icon_smile.gif[/img] Речь о том, что кроме скомпилированные -- и, вероятно, быстрых -- объектов COM в проекте будет также связующая среда на интерпретируемом языке, которая "коммутирует" эти объекты. Ради этой связующей среды мы тащим за собой транслятор и имеем потери в скорости.

Это все чистая правда. Но здесь важно, каковы пропорции между функциональностью, реализованной в COM и, к примеру, на VBScript'е. В нормальных условиях работает правило 10/90: 80% функций реализуется в COM-объектах, 10% -- за счет сопряжения этих COM-объектов.

Если же пойти по пути начинающих asp-разработчиков, когда 90% кода пишется на васике, а 10% составляют стандартные или собственные компоненты -- тормоза получаются, естественно, совсем иного порядка. В том числе -- и за счет трансляции "на ходу" исходного кода.

<BLOCKQUOTE>quote:<HR>Автор Сообщения Original Demon:
На www.citforum.ru Мне кажется, стоит ориентироваться в первую очередь на скорость и качество _разработки_, а потом уже на производительность продукта.<HR></BLOCKQUOTE>

Парадокс в том, что грамотное использование компонентной архитектуры сказывается и на скорости разработки. [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE>quote:<HR>Автор Сообщения Original Demon:
Используйте трехуровневую модель. Падение производительности окупит скорость разработки.<HR></BLOCKQUOTE>

Что конкретно ты имеешь в виду под трехуровневой моделью в данном случае? [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE>quote:<HR>Автор Сообщения Long:
Crazy, это жизнь веб-программиста, от этогу никуда не уйти, поэтому ООП в вебе ограничено по применению.<HR></BLOCKQUOTE>

Странно, но моя жизнь в этом плане складывается куда менее драматично. [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE>quote

Цитата:

И надо очень аккуратно подходить к его использованию.

IMHO, это в равно степени относится ко всему -- от ядерной физики до туалетной бумаги. [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE>quote

Цитата:

А по поводу тормозов СОМ технологии это данные статьи. Сейчас уже не вспомню линку на оригинал. [img]images/smiles/icon_sad.gif[/img] Дело в тормозах интерфейса СОМ-объектов, это аналогично случаю ODBC и ADO, например.

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

<BLOCKQUOTE>quote:<HR>Автор Сообщения Crazy:
Что конкретно ты имеешь в виду под трехуровневой моделью в данном случае? [img]images/smiles/icon_smile.gif[/img]<HR></BLOCKQUOTE>

data tier
business tier
user tier

к каждому уровню свой подход. объем повторно используемого кода будет расти с течением времени. вот мы и получим то самое преимущество ООП.

В случае веба я б таки посоветовал раcщепить presentation tier на два слоя...

[ 30 Апреля 2002: Исправлено Crazy ]

<BLOCKQUOTE>quote:<HR>Автор Сообщения Crazy:
В случае веба я б таки посоветовал раcщепить presentation tier на два слоя...

[ 30 Апреля 2002: Исправлено Crazy ]<HR></BLOCKQUOTE>

По какому принципу? [img]images/smiles/icon_confused.gif[/img]

По расположению. Часть живет на сервере, часть -- на клиенте. В случае, к примеру, Javascript-rich интерфейса это весьма пользительно.

Ну тут надо смотреть опять-таки конкретный случай.

Лучше всего скинуть ВСЕ на клиента. В Intranet-решениях это запросто можно себе позволить.

В любом случе это уже топология, а я говорил про логическое разбиение.

DeДверь
Логин:
Пароль:
	Автологин