ponaehal

Скажите, пожалуйста:
1. Вам нужно держать одинаковыми две таблицы, а что с остальными таблицами? Они могут быть одинаковыми или должны быть разными?
2. А что в MS SQLServer можно настроить репликацию для одной отдельно взятой таблицы?
3. Рассматривали ли Вы вариант на нужную таблицу повесить триггер и по dblink изменять целевую таблицу в другой системе?

Меня смущает постепенное падение производительности.
По моим, ничем не подтвержденным ощущениям, причина кроется в механизме поддержки транзакционности используемой вами базы данных.
Вы пытаетесь вставить кучу записей в одной транзакции, механизмы поддержки отката транзакций (на случай выполнения команды rollback или падения сессии) требуют значительных ресурсов БД. Примерно на 100.000, этих ресурсов хватает, а затем начинается какой то трэш (нужно читать в зависимости от БД).
Что бы я посоветовал для начала:
1. Средствами администрирования БД, посмотреть на расходование ресурсов (понять на что расходуется).
2. Если мои догадки подтвердятся то вам вряд ли поможет пакетная вставка (хотя в разных БД она может быть реализована по разному).
3. Попробуйте вставить commit через каждые 50.000 записей. Тем самым Вы снимите нагрузку с механизмов поддержки отката транзакций.

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

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

ISO 12207 + common sense + 3 года работы в этом направлении

Хм, по моему Вы выдвигаете противоречивые требования.... С одной стороны хотите работать в команде, т.е. что бы другие члены команды зависели от результатов вашего труда, а с другой стороны хотите независимости...
Представьте, вы менеджер, который с пеной у рта выбил где то заказ, взял на себя обязательства по срокам и деньгам, и тут ключевой разработчик заявляет: "а я сегодня не могу, у меня планы..."
Если я не прав в своих предположениях, то почему вы не рассматриваете возможность работы в организации? Ведь если климат в подразделении здоровый, то почти всегда можно просто отпроситься на пару часов, взять пару дней внеочередного отпуска или отпуска за свой счет.

Найдите работу по той теме которую хотите освоить. Для этого честно признайтесь на собеседовании что ни черта не умеете и готовы рассмотреть предлагаемые варианты оплаты. За год-два работы освоите (если повезет и будет у кого поучиться) уровень который вам никогда не дадут ни в одном ВУЗе.

- Я купил телевизор, как мне сделать из него холодильник?
- Очень просто: продайте телевизор и купите холодильник...

Когда руководитель подает заявку на подбор персонала в "отдел кадров", он в заявке указывает пороговый размер оклада на данной позиции. HR'у в общем то все равно, сколько Вам заплатят. Его задача подобрать кандидата с учетом имеющихся требований и ограничений (в т.ч. по з/п).
Отсюда следует:
1. Если у Вас в резюме указана з/п и Вам позвонил HR, то скорее всего компания готова платить деньги которые указаны у Вас в резюме. А вот готовы ли их платить Вам - станет понятно по результатам общения с потенциальным руководителем?
2. Есть смысл указывать в резюме з/п чуть выше вашей собственной оценки себя любимого. Вас подкорректируют))
3. Всячески избегайте прямого ответа на вопрос от HR: "За какую минимальную сумму вы готовы работать" - будьте уверены, если ответите на этот вопрос конкретной цифрой то ее Вам и заплатят. Правильный ответ звучит так: "Мне бы хотелось получать вот столько (завышенная сумма), но я готов этот вопрос обсуждать в рамках общей картины с учетом иных факторов (удобство расположения и комфорт офиса, коллектив, премии, ДМС для семьи и т.п.)
4. Помните: предметный разговор по оплате может быть только после того как вы понравились непосредственному руководителю. Все остальные вопросы в части оплаты направлены на то, чтобы определить, а стоит ли вообще с вами продолжать общение.

Есть всякие полезные функции определения NULL значения типа NVL/NVL2 (Oracle), но подозреваю, что в разных СУБД они реализованы по разному. И все равно общий смысл будет таким:

WHERE
        (tasks.project_id = ".$_SESSION['selected_menu_item_id']." 
AND tasks.author_id = '".$USER['id']."'")
OR (".$_SESSION['selected_menu_item_id']."  <b>is null</b>
AND tasks.author_id = '".$USER['id']."'")

Для того что бы понять/почувствовать язык SQL - вполне достаточно MySQL.
Как только изучите 4 основные команды DML и парочку команд DDL, можно задуматься о различиях и о конкретной платформе. Сугубо ИМХО.

Сей процесс называется транспонированием (см. тут). Делается он либо выражениями PIVOT/UNPIVOT, либо построением запроса типа

select group_concat(if(v='a', c, null)) a, 
       group_concat(if(v='b', c, null)) b, 
       group_concat(if(v='c', c, null)) c
  from (select value v, Count(value) c
          from t1
        group by value ) temp

Ну может еще как то можно...

ИМХО:
1. Если "продвинете" программиста не сдавшего экзамен, то своими же руками дискредитируете экзаменационную систему которая есть в компании. Дальнейшее ее существование не имеет смысл.
2. Если считаете что система не объективна, то поменяйте ее или отмените. Следует понимать, что если менять систему часто, то это само по себе будет дискредитацией системы.
3. Людям свойственно приспосабливаться к любой системе (KPI, грейды, разряды и т.п.). Если человек не хочет этого делать, то поговорите с ним по душам - возможно в его глазах система уже дискредитировала себя (например, при предыдущей сдаче экзамена, он увидел необъективность) или он чем то демотивирован.
4. Из двух зол (если они неизбежны): разрушить работающую систему или потерять хорошего сотрудника, я бы выбрал второе.

Я считаю, что индексы добавлять нужно, ровно как и всевозможные ключи и ограничения.
1. Все это дает оптимизатору подсказку по правильному построению плана запроса.
2. Записи в таблице не упорядочены на диске. Если понадобится чтение с диска (если таблица не в памяти) для того что бы считать таблицу, может понадобиться много операций чтения. С индексом проще.
3. Отсутствие индексов по внешнему ключу может привести к блокировкам при вставке.
Понятно, что есть куча НО (по ситуации), но если затраты на добавление записи в индекс не критичны, то я за то что бы строить индексы и собирать статистику....

Естественный процесс, увы, никуда от этого не денешься....
Так не только в программировании, так во всем. Вам же не нужно знать весь курс физики и электротехники что бы вкрутить лампочку... Вам не надо знать как работает карбюратор/инжектор чтобы ездить на машине...
И опять же даже среди электриков есть те кто способен посчитать нагрузку на сеть, что-то там еще (ничего в этом не понимаю), а есть те которые могут провода в стенку "заштробить" и розетки с автоматами поставить. Но если бы таких не было, то вызов электрика "с образованием" обходился бы нам в круглую копейку.
Экономика блин.... ненавистное слово для перфекциониста :)
Не переживайте так! Удачи!

Ребят, спасибо за ответы, подчерпнул много полезного, но вопрос, ИМХО, несколько шире...
Да, конечно есть вопросы и в ИТ, например:
Вы разработали ТЗ(BRD/SRS/ЛюбуюДругуюБумагу) на какой то функционал, отдали в разработку, реализовали, через полгода нужно внести изменения, что вы делаете: вносите изменения в существующий документ -ТЗ? делаете новое ТЗ (касающееся только изменений)? просто завешиваете таск в соответствующей системе? Как потом это все увязываете вместе?
А может Вы вообще принципиально не пишите ТЗ, считая что достаточно сделать Vision/концепцию, согласовать его с бизнесом и пофиг на будущие поколения разработчиков - почитают Vision + залезут в код и разберутся. Это ведь тоже подход, т.к. у любых знаний есть цена: иногда дешевле/быстрее восстановить знания по коду чем прочесть и понять документ.
А есть еще куча документов (или иных элементов знаний, типа wiki): схемы процессов, архитектурные артефакты для каждого из них свой порядок работы (что то регулярно обновляем, что то оставляем как есть на веки вечные)
А некоторые знания возможно нет смысла сохранять в виде документа, а проще получить из какого то инструмента автоматизиции при необходимости, например: топология компьютерной сети, схема модели данных в БД и т.д. Наверное порядок работы с такими знаниями тоже должен быть определен (или не должен?) и понятен тем кому эти данные могут понадобиться...
И так далее....

А теперь, если ко всему вышесказанному добавить вопросы иных подразделений компании:

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

Я себе это вижу как единую "номенклатуру дел" в которой определены все элементы знаний в организации в виде таких артефактов (намеренно не употребляю слово "докумнетов") как:

• Регламент процесса;
  
• Схема процесса;
  
• Тикет/заявка/ТЗ/BRD/SRS/ЛюбаяДругаяБумага на разработку;
  
• Топология сети;
  
• Диаграмма потоков данных между системами;
  
• Инструкция пользователя;
  
• Должностная инструкция;
  
• Позиция по юридическому вопросу;
  
• Перечень часто задаваемых вопросов для специалистов контакт центра;
  
• и т.п.
  

По каждому артефакту определена форма (в т.ч. в каких то случаях это может быть wiki, инф.система, файл или плакат на бумаге), порядок его создания, обновления, хранения, удаления, интересанты, связи с бизнес-процессами компании, связи с информационными системами и т.п.
А потом это как то увязано с реальной жизнью. Не остается на бумаге, а становится живым документом/процессом/порядком.

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

Хочу понять насколько мое видение утопично, встречался ли кто-нибудь с подобными проблемами? Как решали?

Есть даже ГОСТ на эту тему.
А вот любопытная работа из жизни (правда не знаю насколько можно доверять источнику)

а так?
DATEDIFF("yyyy", BirthDay, GETDATE()) <= 5
Еще неплохо было бы убедиться что BirthDay и GETDATE() имеют именно тот тип данных который нужно подать на вход DATEDIFF.
пруф