funikovyuri Валентин К

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

Заблуждение - цена знания.

[quot Lamer@fools.ua
З.Ы. Складывается впечатление, что Вы чужие сообщения толком не читаете. Я не претендую на роль гуру, но вот высказывание Решение может быть эффективным даже без контекста, с этим я на 100% поспорю. Например поиск по индексу - он не зависит от контекста задачи. выставляет Вас явно не в лучшем свете. СУБД принадлежит контексту задачи. И реализация индексирования в конкретной СУБД тоже принадлежит. От реализации индексирования и подсистемы обработки запросов (как минимум) в конкретной СУБД зависит эффективность использования поиска по индексу.[/quot]

Ладно, вернумся немного назад.
Задача внедрение системы учета, направление задачи - управление изменениями при внедрении программного продукта.
Алгоритм поиска по индексу в контексте управления измененими несет сильно большой смысл. Я понимаю, что это просто софистика, но для того, чтобы было понятнее иногда приходится отделать теорию от практики.
Кстати в конкретном случае с субд сравнивать алгоритм поиска по индексу и перебор значений вообще выходит за область алгоритмов поиска по индексу. Т.к. при переборе значений нет индекса. Тем не менее, если уважаемый афтар съехал с темы, тогда съехал и я, абстрагировав задачу от индекса вообще. В своем глазу... знаете ли.

softwarer
Валентин ККак должен быть сформирован индекс, чтобы поиск в нем был при любом кол-ве данных одинаков? т.е. для поиска 1-го значения по ключу понадобилась бы 1 операция?
Для сведения: это называется O(1).
Что ж, один из возможных ответов - "такой индекс называется индексом массива".
насчет "для сведения" - мне говорить не нужно, просто манипулирование понятиями, о которых не знает аудитория - не самое мое любимое дело, если же вы знаете что это такое - значит я неправильно оценил аудиторию. Но в контексте других ответов я не думаю, что сильно уж занизил познания собравшихся в области быстрого манипулирования данными.

Я не отрицаю ненужности существования 3-х звенной архитектуры. Когда она была сильно в моде достаточно плотно ее изучил и сделал выводы.
Выводы к сожалению не на стороне 3-х уровневой архитектуры, я с удовольствием буду присать в 3-х уровнях, но только если за это заплатят.

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

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

Щас конечно накинутся прохожие и начнут ногами пинать, типа гад какой, обосрал на корню великие идеи, опустил до плинтуса чаяния начинающих программистов в то, что крутизна возможна настолько заоблачная, что писять кипятком хочется и пр... :)

softwarer Валентин КЗаблуждение - цена знания.?
Похоже, Вы настроены выплатить цену по полной программе.

Вы себе льстите. Плюс, похоже, считаете, что "плыть против течения" - менее (либо более) глупое занятие, нежели "плыть по течению".


Философия не относится к вашим сильным сторонам.

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

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

Вывод: массовое заблуждение не порок. Открывать глаза - ни есть моя цель, заблуждайтесь наздоровье.

Ебитесь в рот, ваш Валентин и К.

[quot ВМоисеевp.s. валентин, думаю Вам стоит дезавуировать ваше последнее сообщение. Право не стоит.[/quot]

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

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

Но это не задачи сервера базы данных. А по своей нагрузке на процессор они мало уступают задаче построения выборки. Решать их в среде сервера и на языке хранимых процедур? Не знаю. Отказался от этой идеи. Многозвенка лучше.


Если хотите я проясню аспекты быстродействия без 3-х звенке, как это рекомендую делать, только далеко не всем. Иногда я могу просто промолчать :) И не в локалке, я давно не манипулирую понятиями, в локальной сети или нет. В системах, которыми я занимаюсь понятие клиентов вообще не рассматривается, т.к. ограничения нет и в работе многопользовательность работает вполне привычно, а если клиентов тысячи, так для работы системы это никак не скажется. Главно просто правильно понимать узкие места и заранее их расширять, но не за счет наращивания некоторого звена, а за счет определенных подходов к понятию движения данных.

ВМоисеевДа, Валентин. Меня интересуют варианты. Ссылку на свою статью ранее давал.
С уважением, Владимир.

С удовольствием прочитал статью
http://www.gotdotnet.ru/LearnDotNet/NETFramework/125377.aspx

По поводу стиля - стиль хорошо выдержан, количество абзацев достаточное. Изложение материала четкое и понятное.стиль - зачот.

По сути статьи. Все правильно, я бы тоже так делал лет так 5-6 назад.
Перечислю и прокомментирую пункты статьи:
1) аутентификации пользователя, инициирующего обмен;
Стандартная идентификация пользователем сервером БД вполне подходит, пароль шифруется.
2) авторизации пользователя в процессе работы;
Полезно, сделать опять же нетрудно, используя запомненные пользователем в клиенте логин и пароль.
3) ограничения доступа к функциям и записям таблиц базы данных
информационной системы (управление доступом);
Стандартная безопасность на уровне базы данных.
4) защиты трафика;
Легко включить ssl-шифрование, и/или туннельное подключение к серверу БД.
5) страничного представления информации клиенту;
Проще некуда, конструкция LIMIT, если поддерживается сервером + оптимизированные на данный вопрос компоненты датасета.
6) компрессии информации;
Не проблема в принципе, достаточно включить компрессию в драйвере подключения к БД, если сервер БД поддерживает жатие данные в соединении. Нужно выбирать сервер, чтобы поддерживал.
7) защиты клиентского приложения от несанкционированной модификации;
Тут фантазии нет предела.
8) адаптации структуры системы к информационной нагрузке,
сервер БД нужно выбирать быстрый, проектировать БД в расчете на высокую нагрузку, т.е. продуманная легковесная структура. - этот пункт на самом деле очень глубокий и краеугольный. Его можно обсуждать долго и нудно. Для правильно решения нужно знать на практике возможности сервера БД и его "захеры".

Раскрытие сути представленной реализации - зачот.
Оптимальность представленных решений - незачот.

Дуче andsmМногозвенную архитектуру применяют именно в тех проектах, где требуется максимальная производительность.

А разве вытаскивать данные из БД, чтобы обработать их на сервере приложений будет быстрее, чем обработать их прямо на месте, в БД ?

и я о томже :)

softwarer
Очень качественные замечания. Чувствуется хватка.
Парирование возможно такое:
Пинать ногами других - очень качественное направление развития карьеры, вот только это не вяжется к технологиям, а в жизни знакомы такие индивидуумы. Приятно поговорить, только вот укусить в ответ не даю :)
В итоге в форуме отсутствуют высказывания по поводу обсуждаемой технологии, раскрывающие тему со стороны вас. Тема абзаца: что-то делать всегда сложнее, чем обсуждать деяния других.

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


Пожалуй это наиболее сильно показывает как бы так сказать, чтобы не обидеть .... "узколобость" и неконструктивность мышления. Хотя академический шарм присутствует и качественно вуалирует отсутствие собственного мнения. Обычная психология, когда собственного мнения нет - либо цеплятся за слова оппонента, либо отстаивать чужие выводы, взятые из книжки. Достаточно сложно сформировать свое мнение, для этого нужно работать в интересующем направлении
За мной никогда и никто не гоняется :)