Лишние join'ы в RDBMS это потеря времени, которое является критическим параметром при обработке big data
Это очень похоже на то, что «обработка» сводится к выборке по ключу заранее подготовленных данных под запросы с заранее известными характеристиками. В мире SQL это называется materialized views.
Но обработка означает также поиск, что с неструктурированными данными как раз стыкуется очень плохо — структурирование для того и производится, чтобы ускорить выполнение определённых задач, в числе которых поиск и обеспечение согласованности данных.
«лишние джойны» разумеется медленнее, чем запрос без джойнов. Вот только многие запросы с джойнами не имеют аналогов запросов без джойнов. И в мире БигДата вдруг становится очевидным, что бывает проще сделать джойн, чем перелопачивать огромный массив данных ради выполнения запроса может оказаться банально долго — значительно дольше, чем запрос с джойнами.
Внезапно! Кто мешает в РСУБД сохранить несогласованные данные и привести их в соответствие по тому же принципу, что в нереляционной системе? В то же время реляционная позволяет задействовать контроль целостности, там где нереляционная просто не обладает соответствующей функциональностью «by design».
Но таки первое впечатление от статьи было именно таким: Ctrl+пробел новички узнают из первых подсказок, а то и ставят IDE уже ради самой этой возможности, очень для новичков ценной. Да и сама IDE достаточно агрессивно «подсказывает». Вот только блог, в котором опубликован этот пост и профиль автора — смущают. Но таки надеемся на развитие сюжета в этом блоге — надеюсь мы дойдём до высшего пилотажа из первых рук )
Вообще это всё же zendcoding, который присутствует (возможно в качестве отдельного плагина — честно, не помню, у меня всегда стоит) в комплекте всей линейки IDE от JetBrains. По поводу emmet — было бы неплохо и его функции, но как заметил Metaller — это ещё в процессе.
Больше всего умиляют заявления подобного рода. Не взлетит — так не взлетит, узнаем, что климат не тот. Взлетит — многие будут кусать локти, у кого была возможность и средства попробовать, но они в нерешительности прожевали сопли.
Не понимаю, что мешает «перетащить с этажа на этаж» право на получение из хранилища в более уютном для золота или хлопка месте? (как собственно оно и обстоит на практике)
Разве код крупных проектов, используемых по всему миру постоянно переписывается с нуля?
Согласен, что определённые практики и представления об «идеальном» устаревают, но вот поддерживать иные вещи действительно приходится в течение нескольких технологических «волн». Разумеется, это не касается сайтов, которые не перерастают даже виртуальный хостинг.
Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра, и хотим собрать прототип, неким образом обрабатывающий его данные. Скажем — строит какието стат. графики.
А Вам не кажется, что решение этой задачи и сводится к TDD в чистом виде?
А если разговор идёт о том, что людям на TDD придётся переучиваться… не понимаю, продакшн всё ещё без автоматического тестирования? Или дело дальше прототипов никогда не доходило?
TDD вообще начинается в тот момент, когда изучаешь новый для себя язык программирования или фреймворк — пишешь различные helloworld'ы, которые тебе показывают, как реально система реагирует на твой код. И этому в общем-то не нужно много учиться, можно только повышать уровень мастерства — систематизируя тесты и налаживая их автоматическую работу, используя межпроектные библиотеки тестов.
Так что, дело не в инструменте, а в анатомии произрастания передних конечностей.
Искренне Ваш, К.О.
Это очень похоже на то, что «обработка» сводится к выборке по ключу заранее подготовленных данных под запросы с заранее известными характеристиками. В мире SQL это называется materialized views.
Но обработка означает также поиск, что с неструктурированными данными как раз стыкуется очень плохо — структурирование для того и производится, чтобы ускорить выполнение определённых задач, в числе которых поиск и обеспечение согласованности данных.
«лишние джойны» разумеется медленнее, чем запрос без джойнов. Вот только многие запросы с джойнами не имеют аналогов запросов без джойнов. И в мире БигДата вдруг становится очевидным, что бывает проще сделать джойн, чем перелопачивать огромный массив данных ради выполнения запроса может оказаться банально долго — значительно дольше, чем запрос с джойнами.
Внезапно! Кто мешает в РСУБД сохранить несогласованные данные и привести их в соответствие по тому же принципу, что в нереляционной системе? В то же время реляционная позволяет задействовать контроль целостности, там где нереляционная просто не обладает соответствующей функциональностью «by design».
«Само» — это те ещё «подводные грабли»
с поправкой на технологию хранения.
www.youtube.com/watch?v=b0cRHsApzt8
Всё-таки здесь рассказываются и возможности которые не очевидны при простом знакомстве со средой
Благо WebStorm его умеет на «ура»
Больше всего умиляют заявления подобного рода. Не взлетит — так не взлетит, узнаем, что климат не тот. Взлетит — многие будут кусать локти, у кого была возможность и средства попробовать, но они в нерешительности прожевали сопли.
Согласен, что определённые практики и представления об «идеальном» устаревают, но вот поддерживать иные вещи действительно приходится в течение нескольких технологических «волн». Разумеется, это не касается сайтов, которые не перерастают даже виртуальный хостинг.
А Вам не кажется, что решение этой задачи и сводится к TDD в чистом виде?
А если разговор идёт о том, что людям на TDD придётся переучиваться… не понимаю, продакшн всё ещё без автоматического тестирования? Или дело дальше прототипов никогда не доходило?
TDD вообще начинается в тот момент, когда изучаешь новый для себя язык программирования или фреймворк — пишешь различные helloworld'ы, которые тебе показывают, как реально система реагирует на твой код. И этому в общем-то не нужно много учиться, можно только повышать уровень мастерства — систематизируя тесты и налаживая их автоматическую работу, используя межпроектные библиотеки тестов.