Так если оппонент не способен даже обосновать свое мнение, вы действительно считаете это мнение важным? Забейте на него.
Велосипедом называют, когда пишут что-то, несмотря на то, что уже есть готовое, доступное решение, которое полностью может решить задачу. То есть бессмысленную трату времени.
Но если готовое решение по каким-то причинам не устраивает, и нужно реализовать свое - это уже вполне рядовое явление, встречающееся на каждом шагу. И это нормально.
Ну если есть, то вместо артманий воспользуйтесь дебаггером, отловите момент вывода данных в окошко и посмотрите откуда программа берет данные перед выводом.
Если вы будете писать практику, вы наткнетесь на эти ошибки, загуглите решения, и получите отличный опыт истории языка.
А это весьма неплохой навык - понимать что было раньше, как стало сейчас и почему.
Такой опыт ведет к интуитивному пониманию как правильно писать, и что может отсутствовать в документации.
Тем более, что данная книга для начинающих, то есть придираться к мелочам не обязательно, даже несмотря на то, что что-то могло устареть.
spaceatmoon, Ну, вопрос имеет смысл, учитывая что сейчас даже средненькое приложение может сгенерировать кучу данных, и было бы неплохо заранее продумать архитектуру, чтобы оптимизировать быстродействие и retention policy. Не уверен, что там нужно шарить в нюансах, но для мидера и сеньора это хорошая характеристика.
А если такое спрашивают у джуниора, то это разновидность "почему люки круглые"
Ну так вы же хотите проектировать архитектуру БД, судя по вопросу?
Для небольших (но не совсем маленьких проектов), отдельный архитектор не нужен, программист должен тоже уметь разбираться.
А если пара десятков таблиц? А если надо продумать какие таблицы нужны чтобы обеспечить максимальную производительность и минимизацию локов для бизнес-задачи?
dicem, Ну для исполнителя - все зависит от того, почему горят сроки.
Обычно сроки внезапно не горят - при грамотном построенной работе о всех "горениях" известно заранее и причины также известны - кто-то заболел, возник блокер который не дает заниматься текущей задачей, нагрузили другой более приоритетной задачей, некорректно оценили сроки на задачу.
То есть внезапно - быть не должно, ну и да - если вы не участвуете в "политических" играх менеджера и заказчика - вы должны либо успевать, либо ставить менеджера/непосредственного начальника в известность как можно раньше.
или воспользоваться * сразу в for