Типичный неинформативный маркетинговый trash. Ни конкретики, ни собственно решений, зато обилие не отягощенных смыслом прилагательных
Помимо высокой производительности, решения Siklu отличаются невысокой ценой, надежностью
Нет, чтобы подробно рассказать, как с помощью этих железок завели интернет в реальную деревню Гадюкино, с какими сложностями столкнулись и во сколько это стало заказчику…
на самом ему не нужна была работа к вечеру пятницы, потому что он не работал с ней в выходные. его бы и понедельник устроил, что автор и продемонстрировал начальнику.
и что с того?
само по себе увеличение количества таблиц не есть плохо. иначе все пихали бы в одну большую таблицу.
действительно, код с полиморфными связями несколько более элегантен (абстрактно), но с практической точки зрения это ничего не дает. с точки зрения производительности, непонятно, что же лучше, связи многие-ко-многим или или полиморфные связи в данном случае. некоторое отклонение от DRY может быть очень даже к месту.
я бы обошелся в данном конкретном варианте именно n-to-n связми, поскольку, как мне кажется, у этих таблицу будут физически разные пользователи, которые будут нагружать эти таблицы неравномерно (вероятно). а значит, когда вопрос коснется оптимизации, кеширования и настройки производительности, вам будет легче это делать с разными таблицами, а не с одной. в т.ч. разносить их физически и даже делить таблицу location на четыре части, если потребуется.
в противном случае, если мое допущение неверно, я бы сделал STI, как правильно отметили ниже.
конечно, все это сделать можно и с полиморфными связями, нет ничего не возможного, но человеко-часы не бесплатны и не бесконечны.
скачиваете zip файл с кодом со страницы гитхаба, распаковываете, находите файл Gruntfile.js и убираете в нем все ОС, кроме mac:
дальше в терминале cd в папку с кодом проекта и
по завершении в папке build/releases будет .app файл.
пока что это больше пиар, чем реальность…
Нет, чтобы подробно рассказать, как с помощью этих железок завели интернет в реальную деревню Гадюкино, с какими сложностями столкнулись и во сколько это стало заказчику…
Вычищенные касты, всегда есть текстовые версии.
Может сейчас пойдет?
Спасибо большое!
неужели оправдано? я уж не говорю о тактильных свойствах этой мебели…
уже делали
«она сарказмировала до десяти раз за вечер..»
само по себе увеличение количества таблиц не есть плохо. иначе все пихали бы в одну большую таблицу.
действительно, код с полиморфными связями несколько более элегантен (абстрактно), но с практической точки зрения это ничего не дает. с точки зрения производительности, непонятно, что же лучше, связи многие-ко-многим или или полиморфные связи в данном случае. некоторое отклонение от DRY может быть очень даже к месту.
я бы обошелся в данном конкретном варианте именно n-to-n связми, поскольку, как мне кажется, у этих таблицу будут физически разные пользователи, которые будут нагружать эти таблицы неравномерно (вероятно). а значит, когда вопрос коснется оптимизации, кеширования и настройки производительности, вам будет легче это делать с разными таблицами, а не с одной. в т.ч. разносить их физически и даже делить таблицу location на четыре части, если потребуется.
в противном случае, если мое допущение неверно, я бы сделал STI, как правильно отметили ниже.
конечно, все это сделать можно и с полиморфными связями, нет ничего не возможного, но человеко-часы не бесплатны и не бесконечны.