Пума Тайланд: срочные - это часть имени системы. Сколько минут - могу посмотреть в понедельник на работе. Почему Ваши не срочные - уточните в своем банке. Обычно это параметр платежки. И это стоит дополнительных денег (и вам и банку).
iliasav: хм, мне всегда казалось, что зачисляете то Вы на счет в банке, к которому привязана карта. Но лучше уточните в банке, в котором у вас счет - как корректно сделать такой перевод.
Дмитрий Макаров: artyom_n: ну кстати тут можно много вариантов придумать. начиная от матрицы герконов в поле - и магнита на роботе, и заканчивая опять-же матрицей светодиодов в поле, свет на которые заслоняет робот. одно но - все эти варианты не различат роботов. т.е. как каждый из роботов поймет, что эти конкретные координаты - его? двигаться по очереди?
ImPuuLsE: JOIN - классическая запись. в принципе SELECT по двум(и более) таблицам c WHERE по объединяющим полям работает ровно так-же. По сути это 2 варианта записи одного действия.
JOIN удобен для отделения объединяющих условий от фильтрующих. Т.е. в Вашем случае Город.idCity=Люди.idCity - это условие объединения, а Люди.Фамилия="Петров" - фильтрующее. Пока таких условий 2-3-5 - можно валить и в 1 кучу. Когда начнете объединять таблиц по 8-10 с кучей условий выборки - JOIN будет более читаемым. С точки зрения исполнения на сервере (на сколько мне известно) - разницы нет никакой.
под задачу - и инструмент. Если у человека на ардуино + роутере на WRT робот получится за неделю, а у Вас на STM32 за год - и оба вы получите удовольствие от процесса, то какая разница? только в том, что вы освоили разные инструменты. Если цель - "поиграться", то углубляться в STM несколько сурово. И до реализации банально может не хватить запала. =)
Mr. Robot: "Терпеть не могу попрошаек." - сложно отнести к коллеге. его вклад в Тостер почти втрое выше Вашего. так что совета он уж точно заслужил. Тем более что ситуация как раз вполне нормальная - человек силен в разработке, но не гуру в архитектуре БД. А уж считать чужие деньги - вообще только карму себе портить.
Максим Гречушников: imho SKU у Вас - это запись в таблице price. т.е. SKU - это сумма товар+сеть+город.
к ней справочник с товарами, сетью и городом. "Вендор" - свойство товара (это если хотите заполнять отдельно. Вторая форма, конечно, требует - но оно Вам надо?).
Mr. Robot: "а во вторых никто здесь не получает ни копейки!" - ну почему, здесь куча вопросов на рабочие темы. Я сам задавал такие вопросы - и мне помогали. И я не раз отвечал на явно не любительские вопросы. Вас напрягает, что человек просит помощи? Вы зря посещаете это ресурс, здесь 90% просит помощи.
за исключением косяка с "третьей нормальной" (здесь нет первой - атомарности. до ссылочной целостности еще далеко) голосую обеими руками за вариант 2. Ибо каждый раз парсить строку - даже индийцы в своих трактатах по тантрическому сексу до такого не додумывались.
Alter-ego: вот и напирайте на профит для бизнеса - увеличение "комфорта" использования сети (1 ввод пароля), увеличение надежности - единое место хранения с архивом/проверкой на вирусы/аудитом изменений и т.д.
про перемещаемые профили - подумайте хорошенько. нормально работает только когда профили занимают ОЧЕНЬ мало места.
с прокси все несложно. если нет опыта в линуксе - поставьте готовую сборку типа IpCop. там вполне комфортная веб-морда и крайне низкие требования к железу.
Michael Skimpy: попробуйте для начала воткнуться в роутер кабелем - и измерить скорость.
802,11g - действительно максимум 54Мбита(это в обе стороны, т.е. 27 в одну). Минус всякие накладные расходы - но в хороших условиях мегабайт-полтора получить должны. 100 килобайт - совсем мало.
