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

Тем не менее, я нашел несколько примеров, когда триггеры имели смысл использовать (по крайней мере, на мой взгляд, они имели смысл). Однако недавно я оказался в ситуации, когда мне иногда может понадобиться "bypass" спусковой крючок. Я чувствовал себя очень виноватым из-за необходимости искать способы сделать это, и я все еще думаю, что лучший дизайн базы данных облегчил бы необходимость этого обхода. К сожалению, этот DB используется несколькими приложениями, некоторые из которых поддерживаются очень несговорчивой командой разработчиков, которая кричала бы об изменениях схемы, поэтому я застрял.

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

• Есть ли у вас личный опыт преодоления препятствий в работе веб-приложений?
• Какие-либо рекомендуемые стратегии повышения производительности управляемого данными веб-приложения?

Моя команда разработчиков работает над веб-приложением (JSP reports, HTML, JavaScript), которое использует базу данных Oracle (PL/SQL). ключевая функциональность приложения заключается в создании отчетов, где пользователь может получить PDFs отчетов на высоком уровне и детализировать их до более низких уровней вспомогательных сведений.

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

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

При реализации объектно-ориентированного поиска иголки в стоге сена у вас, по существу, есть три альтернативы:

1. needle.find(haystack)

2. haystack.find(needle)

3. searcher.find(needle, haystack)

Что вы предпочитаете и почему?

Я знаю, что некоторые люди предпочитают второй вариант, потому что он позволяет избежать введения третьего объекта. Однако я не могу избавиться от ощущения, что третий подход более концептуально "correct", по крайней мере, если ваша цель-моделировать "the real world".

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

• Реально или есть какие-то известные проблемы?
• Может репликационный трафик можно как-то жать, для экономии канала?
• Стоит использовать встроенный в MySQL ssl или лучше паковать все в OpenVPN?
• Какие подводные (или даже вполне надводные) камни встретятся, если к этому еще прибавить master-master?
• Кто чего скажет о кластерных типах БД в MySQL?

Один из моих любимых инструментов для linux - это lsof -настоящий швейцарский армейский нож!

Сегодня мне стало интересно, какие программы в системе WinXP имели конкретный открытый файл. Существует ли какая-либо эквивалентная утилита для lsof? Кроме того, файл, о котором идет речь, был на сетевом ресурсе, поэтому я не уверен, что это усложняет дело.