Год назад меня знакомые приглашали в Газпром разрабатывать новый проект с нуля. Очень интересная работа, да и вознаграждение у Газпрома неплохое (кстати не заоблачная з/п) + социалка. Отказался. А знаете почему? Потому что рабочий день с 8 до 8.
В перспективе, офисное рабство сменится таким же рабством дома за собственным компьютером и еще неизвестно что лучше.
Тем не менее поддерживаю ваши идеи, просто такая схема работы не масштабируется на любую IT-деятельность и любых исполнителей.
К примеру, у нас в компании несколько человек заняты разработкой под мобильные терминалы сбора данных. При стоимости среднего терминала в 40-50 тыр на столе такого разработчика может лежать по полляма денег. Никто не даст им такую работу домой.
это не Scale on Demand а скорее Refactoring on Demand
Тем не менее такая схема на мой взгляд единственно верная для стартапов, сильно ограниченных в ресурсах.
Лучше потратить ресурсы на продвижение, чем сделать идеальный с технической точки зрения продукт, которым никто не пользуется. Ведь полпулярность продукта мало зависит от «нормальности» его БД, согласны?
да, и мало-мальски сложный продукт по-любому будет прибит гвоздями к реализации SQL, хотя бы в силу отсутствия внятных стандартов на синтаксис хранимых процедур.
должен, но если не сможет? Firebird, например, в упор не знает сколько записей в табличках, и на простейший запрос SELECT COUNT(*) FROM table будет каждую запись подсчитывать, проверено неоднократно.
Другое дело что запрос логически не корректен: вам надо узнать есть ли вообще записи, для этого достаточно получить только одну, а не считать их кол-во:
Зря вы так думаете. Многие SQL-разработчики любят проверять набор данных на пустоту конструкцией вида (SELECT COUNT(*) FROM ....) > 0, которая запросто может положить на лопатки сервер даже с одним подключением, стоит только целевой табличке вырасти до пары лямов записей.
Железки нужны чтобы отлаживать на них программы. На эмуляторах такой специфический софт не отладить.
Тем не менее поддерживаю ваши идеи, просто такая схема работы не масштабируется на любую IT-деятельность и любых исполнителей.
К примеру, у нас в компании несколько человек заняты разработкой под мобильные терминалы сбора данных. При стоимости среднего терминала в 40-50 тыр на столе такого разработчика может лежать по полляма денег. Никто не даст им такую работу домой.
Тем не менее такая схема на мой взгляд единственно верная для стартапов, сильно ограниченных в ресурсах.
Лучше потратить ресурсы на продвижение, чем сделать идеальный с технической точки зрения продукт, которым никто не пользуется. Ведь полпулярность продукта мало зависит от «нормальности» его БД, согласны?
Кстати у меня закрались сомнения что TOP описан в стандарте SQL99. Пруфом не поделитесь?
и вы еще призываете не использовать «странные и сомнительные СУБД»
SQLite вообще ничего не умеет, его область применения очень ограничена.
>> А нечего использовать странные и сомнительные СуБД
Вы разжигаете?? Тогда пишите минимум 5 пунктов почему Firebird это плохо
Другое дело что запрос логически не корректен: вам надо узнать есть ли вообще записи, для этого достаточно получить только одну, а не считать их кол-во:
SELECT 1 FROM table LIMIT 1
Если не напишите, это сделаю я, идея меня уже зацепила