Gluttton

Не совсем понятно:
— для чего необходим СУБД (разработка, поставка вместе с ПО, разворачивание на сервере предприятия);
— на какое железо предпологается ставить СУБД (количество ядер процессора, количество оперативной памяти);
— объем БД (в байтах и в количествах записей);
— соотношение действий при обращении к БД (чтение, вставка, удаление, обновление);
— дополнительная специфическая ифнормация.

Думаю между MSSQL 2005 Standart и Workgroup. Какую лучше выбрать, сколько стоят и где можно приобрести?

Ну конечно же Standart версия лучше (точнее сказать менее ограничена). За остальное на знаю — сталкиваться не приходилось.

Ну и в заключении: уверен, что вы рассматривали Express версию — чем она не подошла?
Возможно ответ на этот вопрос и станет ответом на ваш вопрос.

У меня есть сервер с svn-репозиторием, доступ по http с path-аутентификацией.
Что бы получить такое сообщение мне нужно попытаться выполнить не разрешенное действие (r, w, rw).
(т.е. есть директории к которым я имею право на чтение, но не имею право на запись — специально проверил и получил похожее сообщение: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/repos/project/!svn/act/7563e694-d243-11df-8ea3-cbb8be9477e5')

Наверное у вас просто не хватает прав.
Как вариант, возможно нет прав на доступ к директории trunk, но при этом, операция может быть разрешена в поддиректории. Т.е. есть смысл попробовать указать поддиректорию trunk.

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

Все написаное ниже — субьективное мнение. Оценка дана мною как пользователя (к дизайну отношения не имею).

Вариант 1: Слово «Data» и прозрачный цилиндр (который у меня ассоциируется с БД), больше подходят на логотип СУБД. Ну и буква «Г» слева вверху, как бы… лишняя… Наилучшая цветовая гамма. Наибольшая ассоциация с IT.
Вариант 2: «Пазл в кепке». Ну-у-у как бы и намекает, но… Не то. Про пазл понял так: «Собираем из компонентов», а вот про кепку или «Мы предоставляем сервис» или «Мы имеем отношение к Red Hat»? Пазлы лучше смотрятся, когда их несколько, мол смотрите — у нас все складывается, а один пазл так и остается не раскрытой загадкой.
Вариант 3: Никих ассоциаций на тему IT не вызвал. В целом не понравился. Ни цветом ни формой ни содержанием.
Вариант 4: Долго не мог понять в чем фишка, но увидев лапочку-пингвинчика все понял! Достаточно интересно. Все равно не совсем то (чего то не хватает), но пожалуй лучший вариант. Скромно, содержательно, минималистично.
Вариант 5: Здорово, но это больше про «сети» или «кабельное телевидение».

Желаю удачи!

Тем, что слишком много логики ложится на модель.

Помоему императивное «жевание» результата декларативной операции так же приведет к увеличению логики.

Сделать class Items_pool и понавешать foreach для каждого случая — первое, что приходит в голову, но чувствую, что это некрасиво

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

Вам виднее, но мне кажеться логичным формирование индивидуального запроса на стороне клиента, (например с использованием хранимой процедуры если количество атрибутов строго ограничено, в противном случае слышал, что может помочь Query Object, но сам никогда не использовал) и получать от сервера «готовые» данные.

Чем не устравивает решение поставленной задачи на стороне SQL-сервера?

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

Дело в том, что когда друзья вступают в деловые отношения, то они оба надеються на дружеское отношение. Например, та сторона, которая должна выполнить некоторые обязательства расчитывает на то, что ему заплатят больше (например) и что если будет небольшая задержка в сроках, то ничего страшного не будет — «ведь мы же друзья». А в то же время другая сторона расчитывает на обратное — что бы обязательства были выполнены в срок и что бы заплатить можно было по меньше — «ведь мы же друзья».

По сему я думаю, что самое главное в таких вопросах это говорить. Говорить и оговаривать все ньюансы. Выдь с деловыми партнерами мы обговариваете все детали до мелочей? А почему с друзьями этого не делать?
Когда я даю в долг денег малознакомому человеку, то я не забываю уточнить все ньюансы: и зачем ему эти деньги и когда он мне их отдаст, а когда берет в долг друг, то такие вопросы задавать как бы некрасиво — естественно потом оказывается, что кто-то что-то не так понял!

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

Помоему существующий подход позволет отсеивать не похожие записи, а идентичные…

Я думаю, что это задача, крайне сложная, если вообще выполнимая и пожалуй это больше не к БД, а к ИИ. Предположим есть два сообщения:
1. Как мне отсивать похожие записи в БД?
2. Какой есть способ предупреждения дублирования записей в БД?
Они похожи?

На мой взгляд лучше всего предоставить решение этой задачи пользователям, например предложив ему перед публикацией взглянуть по ссылке типа «А здесь смотрели», в которой например в порядке реливантности будут идти 5 — 10 ссылок на сообщения, в которых, максимально встречались слова из публикуемого сообщения. Так же можно приспособить для этого теги и искать сообщия не только по словам, но и по тегам (или же вообще только по тегам).

Ну это так, полемика. На практике с таким никогда сталкиваться не приходилось.

Так: ping.eu/ping/?