Ну вот я так же поступаю, 2 вариант — если есть еще дополнительные атрибуты у связи или еще таблицы, которые ссылаются не на сущность, а на саму связь. Но вот вопрос в том, что частенько первый случай перетекает (расширяется) до второго, и не лучше ли всегда делать оп второму варианту, чтобы не менять структуру базы потом, когда добавятся атрибуты и ссылающиеся на связь таблицы? Чего-то я стал склоняться ко второму, но пока смущает.
Опытным путем заметил, что самое эффективное время у меня с 3 ночи до 5 утра, не зависимо от того, встал ли рано или дождался этого времени не ложившись. Но это может быть не для всех верно, я как-то уже лет 10 в режиме по 4-7 часов сна в день и вполне комфортно.
На самом деле, как наем, так и увольнение могут как поднять производительность, так и снизить. С одной стороны — хорошие профессионалы могут снять с Вас часть нагрузки, но даже на профессионалов, не говоря уже о неопытных, нужно тратить время, чтобы «построить» их, чтобы организовать работу, переговоры, совещания… В общем, я часто вижу ситуацию, когда выдать задание, менеджировать процесс исполнения и провести тестирование — дольше, чем сделать самому )
Уточните задачу, тут выбор может быть по разным критериям, по функционалу, объему данных, скорости работы, возможности максимально использовать память и процессор. Разные СУБД имеют разные ограничения, например, по размеру базы, максимальной длине поля, размеру записи и таблицы. Базы есть реляционные, объектные, ключ-значение, иерархические, сетевые и т.д. Нужно хоть с типом определиться. Потом есть такие параметры, как поддержка полнотекстового поиска, поддержка операций с полигонами, поддержка разных типов репликаций и т.д. Полного обзора Вы не найдете, но частичные легко нагуглите в инете. Или же уточните задачу и тут Вам подскажут.
Если бы еще этот переключатель поставили сделали бы прямо на рабочем экране GMail, а не в настройках, иногда хотелось бы и цепочки гляуть, но вообще, при цепочках иногда сложно найти письма, например, если цепочка началась 3 месяца назад, а последнее письмо в ней месяц назад, но я помню толькоко дату первого письма (кода тема началась), то найти уже его по дате невозможно в цепочках. Да и сортировки по колонкам у них нет, это позор по юзабилити.
Это не моя идея, это классический подход. Например класс Image имеет метод Invert. А класс Book имеет свойство Thumbnail класса Image. Код инвертирования не принадлежит Book, а принадлежит Image и когда нам нужно нам нужно инвертировать этот тумбнейл, то пишем Book.Thumbnail.Invert(); Еще есть способ сделать статический класс с утилитами по обработке графики и тогда вызов будет в импорвизированном псевдокоде (я ж не знаю на чем Вы пишете) такой: ImageUtils::Invert(Book.Thumbnail); Задача в том, чтобы не смешать служебное и прикладное и чтобы код группировался по классам и файлам не вызывая перегруженности, и при этом не накрутить сложности.
Но уж больно красив и приятен на ощупь, и цена прямо удивляет. Я эксплуатирую уже пару месяцев, очень нравится, если бы я не раздавил матрицу и не влетел в замену, стоимостью в $300 с ужасным сервисом в Киеве, где мне сначала напарили матрицу вообще от другого ноутбука, то был бы вообще доволен, а теперь подумываю, не заказать ли для конторы 3-4 таких компа из штатов.
Ну это смотря для каких целей, в SQL не все сделаешь, возможностей у него поменьше чем у языков программирования, да и навешивать тригеры на каждую таблицу — не самое удобное. Но вот с другой стороны, к этим логам, записаным на тригерах можно так же делать запросы, то есть, делать версионную базу данных, например, хочу получить запрос к данным по состоянию на такое-то время. С логами это было бы сложнее, там парсить логи по дате и времени, парсать там все эти INDERT/DELETE, потом как-то склеивать… почти не реально.
Имел в виду партфолио на своем сайте, как сборник ссылок, картинок и описаний готовых проектов. По опыту могу сказать, что когда на своем сайте раздел портфолио открыт в свободный доступ, то его передерают молниеносно и о обязательно, поэтому я и у себя другим советую его запаролить, ведь доказывать сложнее, чем предотвратить. И главное, почему нужно иметь портфолио еще и у себя — с течением времени клиенты «портят» свои сайты, докручивая там невесть что сбоку, иногда какие-то совсем левые картинки, или проекты закрываются/продаются и редизайнятся, в общем, через два-три года смотришь, а половина сайтов уже не так выглядят, как при сдаче работ. Поэтому, скриншоты лучше оставлять у себя и на своем сайте. А .htaccess — да, еще один хороший способ.
Ну и еще защита от таких ситуаций — положить свое портфолио под пароль и давать клиентам пароль (даже без логина). Обычно эти горе-веб студии ищут именно чужие портфолио и передерают, а сайт не добавленный в портфолио вряд ли попадет к ним. В этом есть еще одна штука: проверено, что все клиенты и даже просто прохожие будут всегда интересоваться «а что же там под паролем то лежит». Ну и рядом с вводом пароля можно сделать форму «запросить доступ» с вводом емейла.
