средствами яваскрипта - нет, во всяком случае невозможно будет скрыть этот блок из кода. Он будет виден если открыть сырцы хтмл/жс. Если же вопрос чисто визуализации блока на странице - куки или элементарно якорный хэш могут вам помочь.
хуже, в СПБ еще и влажность дикая, в "сильные морозы"(да и в несильные) кроме, собственно, температуры, вы еще ощущаете непередаваемую гамму из ветра и сырости, пронизывающую до костей.
ZakkMalin, только на вас никто ориентироваться не будет, и от чего такая уверенность что все что вы вычисляете будет в итоге рациональными числами? Вы собираетесь всю свою программистскую деятельность сосредоточить в области написания калькулятора для сложения чисел не более 3?
sangan, класс! Мне тоже кажется что я дал хорошее объяснение вопросу, точнее даже "попал своим грязным пальцем прям в больное место", но без элементарных знаний архитектуры приложений и правил проектирования бд вы будете всегда писать каку. Советую все же прочитать про нормальные формы.
Если я правильно понял ваше описание - поле актуальное наличие противоречит 3 нормальной форме, из за этого возникает вопрос как его контролировать в денормализованной структуре. Так?
ZakkMalin, предвидя следующий вопрос "почему тогда процессоры не делают дохриниллионразрядными?" - во первых дорого, сложно и адски греется, так как все что проходит по шине - это электричество, и есть определенное количество энергии на определенную площадь которое можно нормально рассеять на текущем этапе развития техники. + Еще куча мелких проблем с размером транзисторов и чипами. Есть вид процессоров которые имеют 128 и 256 бит шину, в основном это графические чипы и асики, но там более простая начинка, заточенная под урезанный набор инструкций, что не дает им адски пылать, в противоположность ЦП, который более универсален и имеет расширенный набор комманд, но греется и на 64 битной шине.
ZakkMalin, нет(иначе нафига было бы их делать?), регистр с разрядностью 64 позволяет обрабатывать например числа с плавающей запятой с бОльшим количеством знаков после запятой в 2 раза быстрее, чем 32 битный, так как выполняет операции над ними в 1 проход, а не в 2-3, как обработка больших чисел на малоразрядных процессорах. Вся загвоздка с вашими рассуждениями о малых числах и малом месте падает при необходимости более-менее точно вычислить число 1/3. вроде 2 маленьких числа, но количество места под их результат деления будет практически бесконечным. И тут уже нужно выбирать - делать высокую точность или экономить место.
ZakkMalin, вы сами привели картинку из вики, и сами ее не прочли? Там же четко пишут что обработка данных за один проход определяется размером регистра. Будет там миллиард или ноль - разницы для процессора нет, будет передано ровно одно слово на регистр. По этому типы данных разбиты на компромиссные размеры, позволяющие в памяти хранить ограниченный, но заранее известный максимальный размер(что бы избежать перемещения по памяти ячеек и ссылок) и при исполнении кода прозрачно конвертируются в размер регистра. По этому "чем большие вы объёмы памяти считаете" никак в сторону ускорения не работает, скорее наоборот, малый объем имеет оверхед по конвертации в слова.
план запроса строится исходя из кучи параметров, таких как текущие размеры таблиц например(часто перебор "в лоб" на малых таблицах быстрее чем лишние телодвижения с индексами), я бы на вашем месте сначала еще замерил быстрее ли получается запрос с принудительным индексом.
после этого Ларка была прямо глотком понятности и прозрачности
это по тому что вы не смотрели внутрь ядра, а сразу набросали бложик на готовых компонентах ) Внутри достаточно серьезный "треш, угар и содомия" в хорошем смысле )
Василий Берестов, симфони достаточно тяжелый для старта имхо, кстати зенд вообще никто не советует, хотя я бы его на один уровень с симфони поставил. Симфони тяжеловат для начинающих, Ю попроще, но и посерьезней чем лара, лара же - простая в освоении но с достаточно сложным ядром "под капотом", если крутить что-то серьезное на ней - имхо будут проблемы с функционалом выходящим за рамки стандартных компонент. Вообще вопрос сложный по сути, все в конечном итоге зависит от уровня гибкости мозгов отдельно взятого программиста. Сам ооп не сложен по сути, просто иначе ставит вопросы юзабилити и модульности, на порядок четче и аккуратнее процедурщины. А мвц - вообще не относится напрямую к ооп, просто весьма удобный паттерн разделения зон ответственности кода. Его и процедурно можно легко реализовать.
