То что вы пишете про деревья и т.п. было задолго до реляционных БД. Почитайте про «иерархические БД».
Проблема РСУБД в том, что они изначально создавались для тех применений, где критически важной является целостность данных. И в связи с эти они крайне плохо масштабируются (ACID, CAP и вот это вот всё). То есть если ваша БД «вылезла» за пределы производительности вашего сервера — у вас начинаются проблемы. Их пытаются решать партиционированием, шардированием и репликацией (и, надо признать, весьма успешно), но тут же теряется целостность (где-то она не принципиальна).
Ну и ещё есть (по ощущениям) вот какой фактор: сейчас стало «не модно» серьёзно проектировать и все хотят «из коробки» получить быстрое решение под свои задачи. И здесь любая подходящая специализированная система легко «уделывает» любую универсальную. Именно поэтому, я думаю, развелось такое количество разнообразных NoSQL (а по факту — NoACID) СУБД. Каждая создавалась под достаточно узкий круг задач.
Не знаю как дела обстоят на самом деле, но такая гипотеза кажется мне очень правдоподобной. Но я бы расширил её некоторым изменением ситуации в части переработки и распространения информации: раньше, чтобы издать книжку нужно было в разы больше усилий чем сейчас для того чтобы завести свой блог, например. То есть, другими словами, снизился порог вхождения.
Скажу больше: «это займёт Х часов работы» — тоже оценка приблизительная. Потому что в одном случае (человек сидит и Х часов занимается только этой задачей) это действительно займёт Х часов, а в другом (когда ему приходится N раз переключаться на другие задачи) это может занять произвольное количество часов, вплоть до бесконечности. Поэтому любые оценки адекватно работают только для очень коротких временных интервалов (именно отсюда стремление к коротким спринтам в agile). Но тут есть небольшой обман — управляемость улучшается, а результативность — вовсе не обязательно.
Разница заключалась в том, что авторы старых книг пытались понять суть, причины, принципы, на которых успех строится. А поняв принципы, разработать на их основе конкретные методики, рекомендации и практику.
Авторы же новых книг сразу давали рекомендации, практики, приемы и уловки. Делай вот так, и будет тебе успех. Почему будет успех – не важно. Не факт, разумеется, что и авторы понимали причину успеха.
Сдаётся мне всё это имеет место не только в книгах по личной эффективности, но и вообще стало массовым явлением. Только нужно «старые» заменить на «меньшинство», а «новые» на «большинство».
ИТ — это не про компьютеры (базы данных и т.п.). ИТ — это про людей (общение, knowlege sharing, смыслы и идеи и вот это вот всё). Мне показалось что статья предлагает совершенно ложный выбор между двумя крайностями: совещание (как единственный метод общения) и их полное отсутствие (как цепочка актов аутичных участников). То есть, по сути, провоцирует :)
Ну, здесь речь явно не про маленькие турбинки. Я себе представил махину размером с автобус которая крутит 600 оборотов в секунду и мне стало жутковато :)
По вашей логике, так и температура — вектор, и вес — тоже вектор
Э-э-э… Вес-то — действительно вектор. Я ещё из школьного курса физики помню что «Вес — это сила, с которой тело действует на опору или подвес». А сила — величина векторная.
Каркасники — самая дешёвая технология. Другие (при прочих равных) — дороже, как ни крути.
Это если в этих «прочих равных» фигурирует пункт «строят профессионалы своего дела, которые чётко следуют требованиям». В реальной жизни это далеко не всегда так. И не на последнее место выходит такая характеристика как «терпимость к возможным ошибкам». Так вот по этому параметру каркасник сильно проигрывает домам из лёгких крупноформатных блоков (пено- и газобетон и т.п.). Одна пароизоляция чего стоит…
Так что если считать просто по стоимости материалов (доски/вата/плёнки против блоки/клей), то каркасник, конечно, чуток подешевле. Но если считать комплексно и закладывать потенциальные проблемы — далеко не факт.
P.S. Это выводы, в том числе, на основе собственного опыта. 10 лет назад стали осваивать дачу и в качестве дома построили каркасник (строила фирма). Тогда мысль казалась вполне удачной. Сейчас (обладая всем полученным за 10 лет опытом) я бы действовал сильно иначе.
Это, я так понимаю (если вернутся к ситуации в статье), приметно так:
— Накатите вот это патч. Если не поможет — грохните прод, он всё равно не работал.
Наследование является одним из четырёх основополагающих принципов ООП.
Проблема РСУБД в том, что они изначально создавались для тех применений, где критически важной является целостность данных. И в связи с эти они крайне плохо масштабируются (ACID, CAP и вот это вот всё). То есть если ваша БД «вылезла» за пределы производительности вашего сервера — у вас начинаются проблемы. Их пытаются решать партиционированием, шардированием и репликацией (и, надо признать, весьма успешно), но тут же теряется целостность (где-то она не принципиальна).
Ну и ещё есть (по ощущениям) вот какой фактор: сейчас стало «не модно» серьёзно проектировать и все хотят «из коробки» получить быстрое решение под свои задачи. И здесь любая подходящая специализированная система легко «уделывает» любую универсальную. Именно поэтому, я думаю, развелось такое количество разнообразных NoSQL (а по факту — NoACID) СУБД. Каждая создавалась под достаточно узкий круг задач.
Сдаётся мне всё это имеет место не только в книгах по личной эффективности, но и вообще стало массовым явлением. Только нужно «старые» заменить на «меньшинство», а «новые» на «большинство».
Ну, здесь речь явно не про маленькие турбинки. Я себе представил махину размером с автобус которая крутит 600 оборотов в секунду и мне стало жутковато :)
Неужели больше 36 тыс. об./мин?!
— Так он же, вроде, болгарин?
— Да? А какая разница?!
Э-э-э… Вес-то — действительно вектор. Я ещё из школьного курса физики помню что «Вес — это сила, с которой тело действует на опору или подвес». А сила — величина векторная.
Это если в этих «прочих равных» фигурирует пункт «строят профессионалы своего дела, которые чётко следуют требованиям». В реальной жизни это далеко не всегда так. И не на последнее место выходит такая характеристика как «терпимость к возможным ошибкам». Так вот по этому параметру каркасник сильно проигрывает домам из лёгких крупноформатных блоков (пено- и газобетон и т.п.). Одна пароизоляция чего стоит…
Так что если считать просто по стоимости материалов (доски/вата/плёнки против блоки/клей), то каркасник, конечно, чуток подешевле. Но если считать комплексно и закладывать потенциальные проблемы — далеко не факт.
P.S. Это выводы, в том числе, на основе собственного опыта. 10 лет назад стали осваивать дачу и в качестве дома построили каркасник (строила фирма). Тогда мысль казалась вполне удачной. Сейчас (обладая всем полученным за 10 лет опытом) я бы действовал сильно иначе.
— Накатите вот это патч. Если не поможет — грохните прод, он всё равно не работал.