Таких вообще не должно быть в компаниях. По кр. мере в местах, ответственных за глобальное планирование. Поначалу, особенно людям с < 5 лет опыта, можно платить даже меньше среднего по рынку — их труд столько и стóит. Но при наработке стажа, т.е. при погружении вглубь корпоративного продукта, их ценность сильно возрастает — таким уже да, надо хорошо платить.
Я хочу донести главную мысль: нельзя создавать в (программерских) компаниях «гонку зарплат», т.к. это априори фэйл, приводящий к уходу нормальных и кучкованию взаимо-покрывающих крыс.
> Я лично знаю программиста, который отвлекается только на обед и в туалет.
Я сам такой был. Мой рабочий день состоял из 4 часов сна и 16 работы. По молодости. Сейчас, когда я пишу серьёзные штуки, я работаю около 3 часов.
Я догадываюсь, что автор очень горд своей системой оценок (больше показателей — выше ЧСВ). Но насколько я могу судить как программист, ЛЮБАЯ попытка «измерить жизнь цифрами» превращается в маразм. Причина? Да потому что вы работаете с ЛЮДЬМИ, а не роботами. Именно поэтому нет роботов-программистов, что ни один робот не может работать в профессии, часть которой составляет ТВОРЧЕСТВО. Плюс сюда техническая интуиция, «настроение», «драйв» и т.п.
Когда я слышу о немыслимых цифрах «85% _рабочего_ времени программиста», мне хочется заржать вам в лицо — вы сами-то пробовали писать программы 85% времени??? Это как заставить шахматиста или художника «давай, твори, до обеда ещё далеко!». Ни один программист на регулярной основе не тратит даже 6 часов рабочего дня на код! Вдвойне вам позор, потому что подобные вещи даже уже описаны классиками. 2-4 часа максимум — вот мои цифры. Всё остальное — отнюдь не Counter Strike, сюда входят дебилы-сотрудники, отвлекающие от дела в самый важный момент, поиск решения, обучение, копание в справке и т.п. Ну и социум, само-собой — поболтать в сети/с коллегами, внеплановый перекус/перекур, задумчивый взгляд в окно, «не идёт мысль» — много чего.
Но главное — все ваши дюймы, часы и LOC'и летят к чертям, когда оказывается, что опытный сотрудник за час создал гибкое, расширяемое ядро, а 10 неопытных тупо неделю ваяли монолитное гуано, которое через 5 лет превратится в неповоротливого монстра на выброс. ЭТО не измерить никак — это бесценно.
Что могу сказать коррелирующего по статье — то, что программисту НАДО ХОРОШО ПЛАТИТЬ. Но категорически БЕЗ ваших смешных «писькомерок», потому что на любую вашу методику я найду 5 эксплойтов, повышающих «очки», но играющих против компании. Запомните, вы работаете с людьми! И если вы ставите людей в условия прямой гонки за деньгами, ТОЛЬКО ГОНКУ вы и получите!
Зарплата должна быть одна и такая, которая позволяет о ней не думать, а полностью сосредотачиваться над работой.
Не так уж и бесполезно, если подумать: не всегда есть возможность быстро выхватить нож/баллончик/гвоздодёр, а так арендовал дрон у метро, настроил на себя, дрон снимает и в случае чего — тут же сигналит ментам «Преступление века!» (а то и стрелят транквилизатором!). И ты идёшь такой спокойный до дверей дома и как в мультике: "… и никого не встретил!" :)
Вы не совсем поняли: я нигде не говорю, что мы НЕ ПЕЧАТАЕМ реквизиты. Цитата:
> «Название магазина» (безо всяких ООО, ЁПРСТ, и прочей мутоты)
> А далее пишите что хотите
Вот там в «далее» можете писать хоть «Дважды Краснознамённый», но мне на первых полосах нужно именно название магаза, куда я хожу: если это магазин «Съешь и умри», но принадлежащий концерну «Красная Сосиска», я хочу видеть «Съешь и умри» — мне как покупателю это важнее. И это не противоречит закону (насколько я смог понять из вашей ссылки, спасибо).
К сожалению, кто-то очень молодой, но не очень умный, решил, что можно издеваться над людьми с отрицательной кармой, вырезая их форматирование из комментариев, поэтому мой коммент выше потерял форматирование {code} и пример чека выглядит неправильно, будучи написанный пропорциональным шрифтом.
На каком «любом»? Принтер? Ксерокс? Кругом были сплошные 14" CRT — что там «напроектирвали»-то? Слепили один дизайн, посмотрели при 800x600 и 1024x768 и успокоились.
Про «восход солнца» надо обладать весьма бурной фантазией! Скорее, напоминает обломки германского флага и несуразные голубые надписи.
Но польза всё-таки есть — теперь дизайнерам нынешнего *овна не стыдно — потому что раньше было такое же *овно. :) Самый ужасный, кривой, непредсказуемый сайт — мелкомягкий, к счастью приходится заходить туда редко.
И что? А у Васи Иванова вообще нет цифр и формул в проекте. Что будем делать? Настырно проталкивать мысль о важности математики или всё же сходим на RSDN? Пока вы там не прочтёте хотя бы 100 вопросов, не вижу смысла тут «я-кать» со своими графами.
Требует, но не от программиста. Почитайте кто и чем занимается в составе девелоперской команды:
Business Analyst
Application Architect
DBA
Programmer
Tester
UX specialist
Designer
Все эти люди «как бы пишут программу», но каждый занимается своим делом. Говорить, что программисту нужно хорошо знать математику — не менее тупо, чем требовать от повара список удобрений для морковки — это НЕ ЕГО РАБОТА.
Это в России привыкли на одном Ване пахать за семерых — отсюда и заблуждение.
Кто юзает оперу, рекомендую обратить на её деятельность через TCPView: в абсолютно бездейственном состоянии (все страницы/картинки загружены) идёт постоянный обмен с сетью 74.125.233.* через порт 443; Как только руками обрубаешь соединение, тут же вылезает ещё три и одно продолжает обмениваться данными. Возможно, это всего лишь «помощь» юзеру незаметно проапдейтить расширения. Но кто мешает тому же АНБ «вежливо попросить» операстов скачивать нужное ПО из нужного места?
Разве одно другому мешает? Пол Москвы — «выпускники» чего-либо, правда работают, прости господи, вплоть до «ленинградки» :)
Хотя речь не о том, а о том, что человек, работающий в Яндексе, не имеет никакого понимания чем занимается программист. Весь этот бред про математику — умилительная, но далёкая от реальности идея.
Выше я уже дал ссылку на сайт — почитайте их вопросы (по реальной работе) и проверьте, сколько там математики.
> Не знаю почему я похож на «дамочку-пиарщицу», но это не так важно.
:))))))))))))) Это важно, потому что речь шла о lperovskaya, с которой и началась эта довольно глупая дискуссия «математика и программирование». А вы это восприняли на себя ввиду излишней занудности и зацикленности — грустный побочный эффект увлечения математикой. :)
> Математика нужна…
Зачем писать банальщину? Вы считаете, что я за 15 лет п-я этого не понял? Это _Я_ вам объясняю, что БОЛЬШИНСТВО п-ских задач даже рядом не стоят с математикой, т.к. решают сугубо компьютерные проблемы — пересылка данных, оптимизации, удобство интерфейса и т.п. Вы нос-то суньте в объявления (ну вот те, которые из реальной жизни) — много там «математики»? Сплошь «похапасты», «облака», «геймдев» и прочее. К чему мне ваши увещевания в математике, месье? Вы совсем не понимаете, что объясняете проф.программисту чем он оказывается занимается! Уж я-то каждый день пишу программы, с людьми разговариваю — мне лучше знать процент вовлечения других дисциплин.
Вот вам сайт: rsdn.ru слэш forum/dotnet/ — сходите что ли, посмотрите чем занимаются люди, чтоб ерунду не писать.
Ну вот! Уже ближе к программированию. Осталось только закрепить мысль:
Программирование ДАВНО уже перестало быть частью «математики» и стало абсолютно самостоятельной областью, со своими методами, концепциями и «аксиомами». Математика, физика, ДАЖЕ ЭСТЕТИКА стали на службе IT, но это никак не превращает программирование в решение задач для тервера. Эта мысль не вызывает споров? Равно как и мысль, что 99% задач программистов даже рядом не стоят с математическими абстракциями.
Отсюда, возвращаемся к изначальному посту: что конкретно компьютерного вы нашли в задачах от тындекса? Они что, общаются с СУБД? Обрабатывают прерывания? По сетям что-то передают? Достаточно глянуть на решения — это же сплошь математика и формулы, накой им компьютеры-то? Проверить, что математик может закодировать цикл? Так это уже вопрос квалификации МАТЕМАТИКА, но никак не задача для профессиональных программистов. А если я вам скажу, что есть такая компьютерная должность «system analyst», вы со стыда сгорите — это как раз тот человек, который избавляет программистов вообще от какой-либо математики/бухгалтерии/физики, превращая требования реального мира в чисто компьютерное ТЗ (надеюсь, не надо расшифровывать?). Верьте мне, я — программист и знаю лучше дамочек-пиарщиц чем мы занимаемся на работе. :)
«Нам нужно нарисовать борщ, для этого воспользуемся картинкой свёклы и напишем программу, выводящую в случайных местах нашу свёклу» — вот такого специалисту по борщам я сейчас вижу, но никак не программиста.
В принципе, этого ответа достаточно, но технически вы не указали никаких преимуществ в пользу NoSQL. Вот требования:
Требование 1. Мультиязычные поля
Ни бог весть какое требование, локализация — уже давно решённый вопрос. NoSQL никаких преимуществ тут не даёт.
Требование 2. Связи
Опять же, даже вы сами указали несколько решений, все они приемлемы в зависимости от требований задачи. И к слову, NoSQL тут вообще ничем не помогает: docs.mongodb.org слэш manual/reference/database-references/ — такое же «костыльное» решение как у обычного SQL.
Требование 3. Объекты с разным набором полей в одной таблице
Ради бога! Не путайте «нам нужно вывести список на страничку» с «нам нужно всё хранить в одной таблице» — это РАЗНЫЕ вещи. Никто не мешает получить десять списков РАЗНЫХ объектов и вывести хронологически, LINQ вам в помощь.
Требование 4. Сложные объекты
Ну сложные, и чо? Та сумбурщина, которую вы описали — не повод прыгать в какие-то маргинальные решения. Тот же JSON в PostgreSQL вполне «поискуем». Я уже в курсе, что PostgreSQL не рассматривался вообще — серьёзное упущение, но всё равно никаким боком не дающее NoSQL преимуществ — весь вопрос лишь в понимании требований.
Итого, вы просто взяли решение «потому что вам нравится» и описали как вы им решили задачу (ещё вопрос, «насколько эффективно») — я бы такую «рекомендацию» не стал бы даже читать, не то что писать. Это натуральный упадок технической подкованности — неспособность «инженерно» подходить к решению задач, но при этом «как бы технически» расписывать целую статью в пользу личного выбора.
«Я выбрал MongoDB, потому что это модно и там есть полноценный яваскрипт в консоли» — вот и весь грустный смысл статьи. :(
Ребят, вы с этими поделиями напоминаете воздухо(падателей)плавателей времён деревянных крыльев, прикручиваемых к рукам — глупо, неэффективно, БОЛЬНО :), опасно. Тем более речь про глаза — самый крупный и важный источник информации в организме. Потерпите, виртуальность обязательно сделают, но сейчас вы (при нулевом вкладе в развитие VR) только зря портите глаза и материалы.
Чек что был — *оно*, так и остался — *оно*, только с небольшим миксом букв.
К слову, я сам чеки храню и использую для налоговой, так вот для меня как ПОКУПАТЕЛЯ раскладка данных должна быть радикально другая! (даже если я не пользуюсь налоговой). Примерный вид:
«Название магазина» (безо всяких ООО, ЁПРСТ, и прочей мутоты)
ДАТА (крупно, желательно как 3 МАЙ 2014)
Далее сразу же покупки (возможно, через линию, отделяющую заголовок от списка):
Носки(7шт) 10
Чернила для 6
9 класса
Лука мешок 123
— ИТОГО: 139.54 (жирным шрифтом)
Всё, это самое главное! А далее пишите что хотите, включая (как выше уже предложили), например, QRCode (JSON) для быстрого ввода в домашнюю бухгалтерию.
Обратите внимание: цена — выровнена, чтобы её легче было сопоставлять (включая ИТОГО). Конечно же, копейки можно опустить (кроме суммы). Длинное название чернил перенесено с отступом. Цена идёт сразу с первой строчки товара — так легче ориентироваться при чтении. Количество товара прижато к названию — так оно не смешивается с цифрами цены. Естественно, однородные товары должны группироваться в одну запись (в некоторых неандертальских магазах это не так).
И главное — НИКАКОГО МУСОРА! Всё, что мне надо как покупателю, я вижу сразу! И ради бога, не будьте идиотами — если я УЖЕ ПРИШЁЛ в магазин, мне НЕ НУЖНА реклама вашего, мать его, магазина мне на чеке! (если только это не узнаваемый логотип, который висит справа, не мешая мне читать)
ЗЫ
Если кто не увидел «правильного» форматирования — это спасибо ХАБРОВЛАДЕЛЬЦАМ — цитирую их ответ: «Нет, пока с системой кармы всё в порядке. Хоть она и не идеальна.» Ну, как демократия в России.
Вы же сами себе противоречите в одном и том же предложении!
> Выбор основан не столько на требованиях, сколько на удобстве разработки в соответствии с требованиями.
Так учитываются «требования» или нет??
Логически рассудите: требование — «хранить разнородные записи». Решение — «берём РСУБД и создаём таблицы» — потому что это классическое, проверенное временем решение на ТЫСЯЧАХ систем. Вы от него отказываетесь. Причина? «Мне не нужно думать — какие данные пойдут в json, а какие в основные поля таблицы, не придется думать о миграции полей из json в поля таблицы и обратно. Не придется вообще работать с таблицами, мне нравится, что у монги есть полноценный яваскрипт в консоли, что мне не придется думать об sql injection...» (к слову, о половине этой белиберды я вообще не думаю — просто решаю задачу)
Другими словами, это даже не «технический выбор», а чисто субъективное «мне не надо думать» (хотя я не понимаю, как можно «не думать» там, где как раз всё ядро системы!). Сунете вы данные в Mongo или SQL, всё-равно придётся заботиться о многих вещах, от консистентности данных до производительности, балансировки нагрузки и шифрования.
Кратко говоря, вы даже не выбирали, а просто «мне так удобно» и бац — поставили MongoDB! И _это_ заслуживало отдельной статьи??? :))) Я потому и написал «диагноз» (разве он не верен?), что ДАЖЕ если у вас были какие-то технические соображения, в этой многословной статье я их не увидел.
«Технический выбор» — это когда:
«Мы сделали реляционные таблицы (схема), в нашей задаче нужно выбрать список бла-бла… получилось вот такое решение (SQL запрос/ORM, объекты) с такими затратами по памяти/времени и вот такими перспективами под будущие нужды. А теперь мы перенесём это в NoSQL — получилась вот такая выборка, вот на столько стало МЕНЬШЕ(?) кода/времени/памяти и вот так увеличилась гибкость по расширению системы». Если бы я это прочёл, я бы выкинул нафик все свои базы, побрил голову (так принято) и пошёл к вам в ученики. :) Но ничего этого я не увидел, поэтому и написал своё мнение: ваш выбор сугубо индивидуальный и не показывает НИКАКИХ преимуществ, почему нужно делать решение именно на NoSQL.
Из требований не увидел ровным счётом НИЧЕГО, что просто требовало бы NoSQL.
Ребята, вы занимаетесь натягиванием задач на технологию, а не применением технологии для решения задачи! Подрастёте — появится понимание, что игры в новомодные баззворды — удел студентов с «бесконечным» временем, а в реальной работе нужны чёткие, проверенные решения.
И главное, кого и в чём вы хотите убедить своей статьёй? Вы СЕБЕ хотите доказать, что не ошиблись? Это называется патологическое враньё, от него нужно лечиться.
Я хочу донести главную мысль: нельзя создавать в (программерских) компаниях «гонку зарплат», т.к. это априори фэйл, приводящий к уходу нормальных и кучкованию взаимо-покрывающих крыс.
> Я лично знаю программиста, который отвлекается только на обед и в туалет.
Я сам такой был. Мой рабочий день состоял из 4 часов сна и 16 работы. По молодости. Сейчас, когда я пишу серьёзные штуки, я работаю около 3 часов.
Когда я слышу о немыслимых цифрах «85% _рабочего_ времени программиста», мне хочется заржать вам в лицо — вы сами-то пробовали писать программы 85% времени??? Это как заставить шахматиста или художника «давай, твори, до обеда ещё далеко!». Ни один программист на регулярной основе не тратит даже 6 часов рабочего дня на код! Вдвойне вам позор, потому что подобные вещи даже уже описаны классиками. 2-4 часа максимум — вот мои цифры. Всё остальное — отнюдь не Counter Strike, сюда входят дебилы-сотрудники, отвлекающие от дела в самый важный момент, поиск решения, обучение, копание в справке и т.п. Ну и социум, само-собой — поболтать в сети/с коллегами, внеплановый перекус/перекур, задумчивый взгляд в окно, «не идёт мысль» — много чего.
Но главное — все ваши дюймы, часы и LOC'и летят к чертям, когда оказывается, что опытный сотрудник за час создал гибкое, расширяемое ядро, а 10 неопытных тупо неделю ваяли монолитное гуано, которое через 5 лет превратится в неповоротливого монстра на выброс. ЭТО не измерить никак — это бесценно.
Что могу сказать коррелирующего по статье — то, что программисту НАДО ХОРОШО ПЛАТИТЬ. Но категорически БЕЗ ваших смешных «писькомерок», потому что на любую вашу методику я найду 5 эксплойтов, повышающих «очки», но играющих против компании. Запомните, вы работаете с людьми! И если вы ставите людей в условия прямой гонки за деньгами, ТОЛЬКО ГОНКУ вы и получите!
Зарплата должна быть одна и такая, которая позволяет о ней не думать, а полностью сосредотачиваться над работой.
> «Название магазина» (безо всяких ООО, ЁПРСТ, и прочей мутоты)
> А далее пишите что хотите
Вот там в «далее» можете писать хоть «Дважды Краснознамённый», но мне на первых полосах нужно именно название магаза, куда я хожу: если это магазин «Съешь и умри», но принадлежащий концерну «Красная Сосиска», я хочу видеть «Съешь и умри» — мне как покупателю это важнее. И это не противоречит закону (насколько я смог понять из вашей ссылки, спасибо).
На каком «любом»? Принтер? Ксерокс? Кругом были сплошные 14" CRT — что там «напроектирвали»-то? Слепили один дизайн, посмотрели при 800x600 и 1024x768 и успокоились.
Про «восход солнца» надо обладать весьма бурной фантазией! Скорее, напоминает обломки германского флага и несуразные голубые надписи.
Но польза всё-таки есть — теперь дизайнерам нынешнего *овна не стыдно — потому что раньше было такое же *овно. :) Самый ужасный, кривой, непредсказуемый сайт — мелкомягкий, к счастью приходится заходить туда редко.
Business Analyst
Application Architect
DBA
Programmer
Tester
UX specialist
Designer
Все эти люди «как бы пишут программу», но каждый занимается своим делом. Говорить, что программисту нужно хорошо знать математику — не менее тупо, чем требовать от повара список удобрений для морковки — это НЕ ЕГО РАБОТА.
Это в России привыкли на одном Ване пахать за семерых — отсюда и заблуждение.
Хотя речь не о том, а о том, что человек, работающий в Яндексе, не имеет никакого понимания чем занимается программист. Весь этот бред про математику — умилительная, но далёкая от реальности идея.
Выше я уже дал ссылку на сайт — почитайте их вопросы (по реальной работе) и проверьте, сколько там математики.
«при нулевом вкладе в развитие VR»
:))))))))))))) Это важно, потому что речь шла о lperovskaya, с которой и началась эта довольно глупая дискуссия «математика и программирование». А вы это восприняли на себя ввиду излишней занудности и зацикленности — грустный побочный эффект увлечения математикой. :)
> Математика нужна…
Зачем писать банальщину? Вы считаете, что я за 15 лет п-я этого не понял? Это _Я_ вам объясняю, что БОЛЬШИНСТВО п-ских задач даже рядом не стоят с математикой, т.к. решают сугубо компьютерные проблемы — пересылка данных, оптимизации, удобство интерфейса и т.п. Вы нос-то суньте в объявления (ну вот те, которые из реальной жизни) — много там «математики»? Сплошь «похапасты», «облака», «геймдев» и прочее. К чему мне ваши увещевания в математике, месье? Вы совсем не понимаете, что объясняете проф.программисту чем он оказывается занимается! Уж я-то каждый день пишу программы, с людьми разговариваю — мне лучше знать процент вовлечения других дисциплин.
Вот вам сайт: rsdn.ru слэш forum/dotnet/ — сходите что ли, посмотрите чем занимаются люди, чтоб ерунду не писать.
Программирование ДАВНО уже перестало быть частью «математики» и стало абсолютно самостоятельной областью, со своими методами, концепциями и «аксиомами». Математика, физика, ДАЖЕ ЭСТЕТИКА стали на службе IT, но это никак не превращает программирование в решение задач для тервера. Эта мысль не вызывает споров? Равно как и мысль, что 99% задач программистов даже рядом не стоят с математическими абстракциями.
Отсюда, возвращаемся к изначальному посту: что конкретно компьютерного вы нашли в задачах от тындекса? Они что, общаются с СУБД? Обрабатывают прерывания? По сетям что-то передают? Достаточно глянуть на решения — это же сплошь математика и формулы, накой им компьютеры-то? Проверить, что математик может закодировать цикл? Так это уже вопрос квалификации МАТЕМАТИКА, но никак не задача для профессиональных программистов. А если я вам скажу, что есть такая компьютерная должность «system analyst», вы со стыда сгорите — это как раз тот человек, который избавляет программистов вообще от какой-либо математики/бухгалтерии/физики, превращая требования реального мира в чисто компьютерное ТЗ (надеюсь, не надо расшифровывать?). Верьте мне, я — программист и знаю лучше дамочек-пиарщиц чем мы занимаемся на работе. :)
«Нам нужно нарисовать борщ, для этого воспользуемся картинкой свёклы и напишем программу, выводящую в случайных местах нашу свёклу» — вот такого специалисту по борщам я сейчас вижу, но никак не программиста.
В принципе, этого ответа достаточно, но технически вы не указали никаких преимуществ в пользу NoSQL. Вот требования:
Требование 1. Мультиязычные поля
Ни бог весть какое требование, локализация — уже давно решённый вопрос. NoSQL никаких преимуществ тут не даёт.
Требование 2. Связи
Опять же, даже вы сами указали несколько решений, все они приемлемы в зависимости от требований задачи. И к слову, NoSQL тут вообще ничем не помогает: docs.mongodb.org слэш manual/reference/database-references/ — такое же «костыльное» решение как у обычного SQL.
Требование 3. Объекты с разным набором полей в одной таблице
Ради бога! Не путайте «нам нужно вывести список на страничку» с «нам нужно всё хранить в одной таблице» — это РАЗНЫЕ вещи. Никто не мешает получить десять списков РАЗНЫХ объектов и вывести хронологически, LINQ вам в помощь.
Требование 4. Сложные объекты
Ну сложные, и чо? Та сумбурщина, которую вы описали — не повод прыгать в какие-то маргинальные решения. Тот же JSON в PostgreSQL вполне «поискуем». Я уже в курсе, что PostgreSQL не рассматривался вообще — серьёзное упущение, но всё равно никаким боком не дающее NoSQL преимуществ — весь вопрос лишь в понимании требований.
Итого, вы просто взяли решение «потому что вам нравится» и описали как вы им решили задачу (ещё вопрос, «насколько эффективно») — я бы такую «рекомендацию» не стал бы даже читать, не то что писать. Это натуральный упадок технической подкованности — неспособность «инженерно» подходить к решению задач, но при этом «как бы технически» расписывать целую статью в пользу личного выбора.
«Я выбрал MongoDB, потому что это модно и там есть полноценный яваскрипт в консоли» — вот и весь грустный смысл статьи. :(
К слову, я сам чеки храню и использую для налоговой, так вот для меня как ПОКУПАТЕЛЯ раскладка данных должна быть радикально другая! (даже если я не пользуюсь налоговой). Примерный вид:
«Название магазина» (безо всяких ООО, ЁПРСТ, и прочей мутоты)
ДАТА (крупно, желательно как 3 МАЙ 2014)
Далее сразу же покупки (возможно, через линию, отделяющую заголовок от списка):
Носки(7шт) 10
Чернила для 6
9 класса
Лука мешок 123
— ИТОГО: 139.54 (жирным шрифтом)
Всё, это самое главное! А далее пишите что хотите, включая (как выше уже предложили), например, QRCode (JSON) для быстрого ввода в домашнюю бухгалтерию.
Обратите внимание: цена — выровнена, чтобы её легче было сопоставлять (включая ИТОГО). Конечно же, копейки можно опустить (кроме суммы). Длинное название чернил перенесено с отступом. Цена идёт сразу с первой строчки товара — так легче ориентироваться при чтении. Количество товара прижато к названию — так оно не смешивается с цифрами цены. Естественно, однородные товары должны группироваться в одну запись (в некоторых неандертальских магазах это не так).
И главное — НИКАКОГО МУСОРА! Всё, что мне надо как покупателю, я вижу сразу! И ради бога, не будьте идиотами — если я УЖЕ ПРИШЁЛ в магазин, мне НЕ НУЖНА реклама вашего, мать его, магазина мне на чеке! (если только это не узнаваемый логотип, который висит справа, не мешая мне читать)
ЗЫ
Если кто не увидел «правильного» форматирования — это спасибо ХАБРОВЛАДЕЛЬЦАМ — цитирую их ответ: «Нет, пока с системой кармы всё в порядке. Хоть она и не идеальна.» Ну, как демократия в России.
> Выбор основан не столько на требованиях, сколько на удобстве разработки в соответствии с требованиями.
Так учитываются «требования» или нет??
Логически рассудите: требование — «хранить разнородные записи». Решение — «берём РСУБД и создаём таблицы» — потому что это классическое, проверенное временем решение на ТЫСЯЧАХ систем. Вы от него отказываетесь. Причина? «Мне не нужно думать — какие данные пойдут в json, а какие в основные поля таблицы, не придется думать о миграции полей из json в поля таблицы и обратно. Не придется вообще работать с таблицами, мне нравится, что у монги есть полноценный яваскрипт в консоли, что мне не придется думать об sql injection...» (к слову, о половине этой белиберды я вообще не думаю — просто решаю задачу)
Другими словами, это даже не «технический выбор», а чисто субъективное «мне не надо думать» (хотя я не понимаю, как можно «не думать» там, где как раз всё ядро системы!). Сунете вы данные в Mongo или SQL, всё-равно придётся заботиться о многих вещах, от консистентности данных до производительности, балансировки нагрузки и шифрования.
Кратко говоря, вы даже не выбирали, а просто «мне так удобно» и бац — поставили MongoDB! И _это_ заслуживало отдельной статьи??? :))) Я потому и написал «диагноз» (разве он не верен?), что ДАЖЕ если у вас были какие-то технические соображения, в этой многословной статье я их не увидел.
«Технический выбор» — это когда:
«Мы сделали реляционные таблицы (схема), в нашей задаче нужно выбрать список бла-бла… получилось вот такое решение (SQL запрос/ORM, объекты) с такими затратами по памяти/времени и вот такими перспективами под будущие нужды. А теперь мы перенесём это в NoSQL — получилась вот такая выборка, вот на столько стало МЕНЬШЕ(?) кода/времени/памяти и вот так увеличилась гибкость по расширению системы». Если бы я это прочёл, я бы выкинул нафик все свои базы, побрил голову (так принято) и пошёл к вам в ученики. :) Но ничего этого я не увидел, поэтому и написал своё мнение: ваш выбор сугубо индивидуальный и не показывает НИКАКИХ преимуществ, почему нужно делать решение именно на NoSQL.
Ребята, вы занимаетесь натягиванием задач на технологию, а не применением технологии для решения задачи! Подрастёте — появится понимание, что игры в новомодные баззворды — удел студентов с «бесконечным» временем, а в реальной работе нужны чёткие, проверенные решения.
И главное, кого и в чём вы хотите убедить своей статьёй? Вы СЕБЕ хотите доказать, что не ошиблись? Это называется патологическое враньё, от него нужно лечиться.