dbmaster

в 999 случаях из 1000 человек не может ничего сделать глядя на 2кк строк. Наш мозг просто не в состоянии оперировать такими объемами сразу. Треть пользователей накладывает нужный фильтр, еще треть делает сортировку по одному значимому для них столбцу, и «мотает» до нужных значений. Остальные пользуются поиском на каждую запись.

Посмотрите к какой трети относятся ваши пользователи. Мне кажется сделать диалог-мастер с фильтром гораздо проще, чем выкабениваться с 2кк записей, 90% которых не требуются пользователю :)

Если у вас данные не лезут в json, как вариант, можно делать дамп таблички в static-file, загружать его, а потом уже ajax-ом доводить до кондиции с бд, если база не часто обновляет записи.

Заглушка должна возвращать HTTP 503, чтобы поисковики не индексировали ее. Для этого подойдет любой хостинг с php:

<?
header('HTTP/1.1 503 Service Temporarily Unavailable');
header('Status: 503 Service Temporarily Unavailable');
echo 'Упс, и такое случается. Наш сайт временно недоступен по причине бла-бла-бла.';
?>

Google Calendar можно настроить. Будет и с мобильника в т.ч. можно настроить права.

За это банить надо. Сервис не помощи в сборах — а простой интернет магазин чемоданов.
Очень некрасиво.

Написать триггер, записывающий ID удаленной/измененной записи таблицы T1 в таблицу T1del.

Прежде чем гадать, проанализировали бы выполнения запроса, и посмотрели, что именно так долго делается. Может, у вас тормозит не обновление, а поиск и просто индекса по полю uid не хватает?

Спам через троянскую программу с IP 188.51.8.179. Зараженный компьютер называется MARLENE-PC и подключен через DSL-роутер. Так что, если это все не ваше — можете спать спокойно.

Можно писать в любом редакторе, поддерживающем MD, а потом конвертить в html, для Sublime Text 2 есть для этого плагины.

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

Можно, если ваш бюджет на рекламу сравним с таковым у Google.

Уже есть Wordpress, Drupal, Joomla, Typo3. Они хороши тем, что есть огромное community, и ставя их я уверен, что всегда недорого найду сотрудника, который решит любую мою задачу.

Поставив закрытую CMS я буду иметь проблемы. Которые решать будет дорого и геморно. Тем более если этой закрытой CMS пользуется мало людей — зачем мне быть подопытным кроликом за свои деньги?

Плюс на этом рынке конкурировать придется с Битриксом. А бюджеты 1С на рекламу немаленькие.

Коммерческая закрытая CMS сейчас может окупиться только если это SaaS.

$ mysqldump -u username -p'password' db-name | ssh user@remote.box.com mysql -u username -p'password db-name

Думаю, что это самый простой вариант

Far manager + ConEmu делает 2х панельный менеджер с закладками итого получаем 2*N панелей. Вопрос только зачем?

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

Навскидку сразу видно несколько проблем.

Во-первых, никакие тесты не должны изменять после себя базу. Если это интеграционные или приёмочные тесты, то их, например, можно проводить в транзакции, откатываемой после завершения каждого теста (кроме того, можно использовать in-memory DB — это заодно и ускорит выполнение тестов). А если это юнит-тесты, то они вообще не должны лезть в базу — надо переписывать код таким образом, чтобы юнит-тестирование не требовало обращений к БД (это, кстати, как правило и общее качество кода улучшает и делает код легче переиспользуемым).

Во-вторых, когда тесты выполняются часами — это верный симптом, что в консерватории что-то не так. Попробуйте отвязать тесты от БД — это должно сильно их ускорить. Если не поможет — разделите тесты по категориям и на каждый коммит прогоняйте только юнит-тесты, а интеграционные и приёмочные выполняйте раз в два-три часа (в зависимости от длительности их исполнения).

Кроме того, если все билды выполняются на одной машине, то их надо выполнять последовательно, а не параллельно — это уменьшает накладные расходы и общее время сборок/тестирования. А вот если вы выполняете сборки на разных машинах (например, TeamCity это умеет) — тогда да, можно запускать и параллельно, чтобы вычислительный ресурс не простаивал :-)

Как вариант, можно создать таблицу translations (text, culture, translation).

Определить функцию translate(text, culture), которая будет возвращать или перевод, если он есть, или изначальную строку, если перевода нет.
Использовать её можно будет с любой таблицей:

SELECT Id, translate(Value), translate(Value2) ...

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

Форменное жлобство

Я уже такое реализовывал. Правда на MSSQL 2000, но суть не меняется.

Все сущности БД содержали такие поля:

OBJECT_ID
OBJECT_NAME
OBJECT_DATE_INSERT
OBJECT_USER_INSERT
OBJECT_DATE_UPDATE
OBJECT_USER_UPDATE
DELETED

Выше — это, как бы, параметры класса Object, от которого наследуются все остальные классы.

OBJECT_ID — уникальный для всех объектов БД.

Один основной сервер выделяет раз в сутки диапазоны ID для локальных серверов, и, собственно, раздает их при новой синхронизации.

Синхронизация проходит в 4 этапа:

1. Выбираем новые объекты, созданные на локальном сервере:
LOCAL_SERVER.OBJECT_DATE_INSERT > LAST_SYNC_DATE

2. Выбираем измененные на локальном сервере объекты с момента последней синхронизации:
LOCAL_SERVER.OBJECT_DATE_UPDATE > LAST_SYNC_DATE

3. Выбираем новые объекты, созданные на всех остальных локальных серверах кроме нашего:
REMOTE_LOCAL_SERVER.OBJECT_DATE_INSERT > LAST_SYNC_DATE

4. Выбираем измененные, соответственно, на всех остальных локальных серверах объекты:
REMOTE_LOCAL_SERVER.OBJECT_DATE_UPDATE > LAST_SYNC_DATE

Ну раз уж холивар, ответ юриста о правовой стороне:
ст. 10 ч. 4 ФЗ РФ от 29 июля 2004 г. № 98-ФЗ «О коммерческой тайне» гласит: «Обладатель информации, составляющей коммерческую тайну, вправе применять при необходимости средства и методы технической защиты конфиденциальности этой информации, другие, не противоречащие законодательству Российской Федерации, меры».
Работодатель оплачивает почтовый трафик, используемый сотрудниками в личных целях, и их рабочее время, потраченное на личное общение. Он же будет нести убытки в случае утечки конфиденциальной информации.
То есть вся переписка, осуществляемая в рабочее время при помощи технических средств, принадлежащих данной организации, и по оплаченным ею каналам связи или передачи данных, является служебной, даже если таковая ведется в нерабочее время.

Могу отдельно статью написать, если это будет интересно многим.