По сути, да. Не корректно выразился. Тут два пути.
Можно расколотить все много мелких таблиц с одинаковыми ключами, либо писать пары «ключ/значение», где значение структурировано как то другим способом (CSV, XML...)
Да. Читалки — хорошо, особо учитывая то, как они дешевеют.
Мне кажется скоро, у них большую долю рынка откусят планшетники, когда дешеветь начнут. Одно толь то, что им не нужна дополнительная подсветка, уже плюс. Кроме того, если есть планшетник, руки к читалке уже не тянутся. Это из практики.
Хочется добавить…
Много сказано про типизированность данных в таблицах. mishinoleg, прав про рост кода в самом приложении. Все приводит к тому, что можно назвать, _самостоятельной реализацией части функций СУБД в своем коде под конкретную задачу_. (выделил подчеркиванием, к сожалению тэги недоступны)
В целом, могу из собственной практики сказать, что нормализация таблиц, по своей сути, близка, к тому, чтобы стать «хранилищем». Достаточно перестать использовать в запросах «join» и начать делать это руками в коде. Последнее, приведет к тому, что вы будете компоновать данные из таблиц наиболее оптимальным для вашей задачи способом. А это скажется на производительности. По сути, таблица в обычной базе с Primary Key и Blob-ом или длинной строкой, вполне может служить таким хранилищем, как ключ/значение. Учитывая наработки в движках SQL, запросы с выборкой по «основному ключу» врятли смогут быть уделаны различными свежими API. Скорее всего, они все таки выиграют.
Все что я хочу сказать, что если использовать реляционную базу просто, не нагружая ее семистраничными запросами, а нормализовав, реализовать большую часть математики и логики на уровне приложения, можно добиться и производительности и масштабируемости.
А вот если бы расписали иерархическую модель данных или сетевую… да еще бы нашли софт, который умеет с этим работать… совсем бы интересно было.
К слову сказать, иерархическая модель очень схожа с XML-структурой.
Фантазируют фантасты. Вы просили отзывов, вы их получили. Переходить на давлеющий тон, из-за комментариев с юмором, не обязательно, если вы уж пишите изнедр компании, а следовательно, в какой то мере от ее лица. Таким образом, вы отбиваете охоту на любой фитбэк от публики, а ведь многие компании на это тратят огромные усилия и ресурсы.
Выделять главную страницу в нечто отдельное, в моем понимании, не системно. Тем более в структурное подразделение компании.
Главная страница, безусловно, для 90% посетителей — первая страница, которую они загружают. Однако она далеко не единственная.
В данном топике я вижу, что люди постарались и кастомизировали лицо сайта под различные устройства с их различным разрешением и свойствами. Это хорошо. А вот то, что это сделало одно подразделение компании, говорит о том, что другие сервисы системы, если и оптимизируют что то, то уже на свой лад. Без унификации. Хоть малейшее отличие в подходах, но будет. Итог — пользователь будет теряться и привыкать к тому, что с одной стороны красное, с другой может оказаться фиолетовым.
Очевидно, что сео умирает. Однако, прямая альтернатива (контекстная реклама), на мой взгляд, неоправданно дорога! И ей нет прямой конкуренции, которой раньше был этот самый сео. Конкуренция между представителями рынка контекстной рекламы — не в счет. Она там не очень сильная. Кроме того, народ всегда ломится к наиболее популярным ресурсам и усиливает эффект монополизма.
Я считаю, что какую то часть влияния могут в ближайшем будущем оказать социальные сети, есть даже мысли, как это сделать, но пока ничего похожего я не видел и ресурсов сделать это самому, тоже нет.
Практический подход к оптимизации (на базе опытов).
Берем в руки микротайм и считаем в узловых точках скриптов время и считаем. В местах, где можно существенно сэкономить — экономим.
Я не могу сейчас уже привести примеры кода, но могу описать ситуацию, когда экономил на выводе больших массивов данных из базы. Удобно, например, при выводе детализаций по всякого рода аккаунтингу (трафик, звонки, смс и прочие тарифицируемые...). Такие данные характерны короткими справочниками с десятками записей и огромной таблицей CDR (собственно записей тарификации). Вот в таких ситуациях, чтение справочников целиком из базы в массив в памяти и использование этих массивов при выводе с одним простым запросом только к таблице CDR в базе, позволяется «разогнать» скрипт в сотни раз, по сравнению с решением в лоб — запросами с join-ами в базу данных.
Конечно, это скорее оптимизация СУБД, но средствами языка программирования. :)
DB-дизайнер кривоват.
Кроме того, много чего не умеет. У меня привычка в любой таблице иметь PK bigint unsigned auto_increment. Там такого не сделать. И видимо много чего… Это всего за первую минуту нашел.
Бурум, мне лично кажется удивительным, как ты до сих пор не открыл свой журнал. Чисто сетевой или глянцевый, не столь важно. Я уверен, что сколотить команду, тебе понадобится не больше недели, причем не на поиск, а на отбор лучших из желающих.
Чую за спиной наводящийся в затылок лазерный ствол НЛО :)
Вы меня не так поняли. SEO-шники именно вымирают и именно сеошники. Потому, что профессию уже иначе называется. Сеошник влияет на выдачу, вернее влиял… А нынешние «продвигатели» это уже не SEO-шники, это «менеджеры по рекламе» :)
SEO-шники, извините, они и в африке Search Engine оптимизаторы. Они вымирают по понятным причинам.
А некоторые мутируют, в рекламщиков, PR-шиков и т.п. Если влиять на выдачу поиска не получается (или становится дорого/невыгодно/не гарантировано), надо искать другие способы привлечения людей… конетекст, баннерная сеть, соц. сети, тематические площадки, агрегаторы предложений товаров и услуг и много-многое другое, на что не обращали внимание, когда достаточно было закупить миллиард ссылок и оказаться чуть ли не выше строки поиска в результатах выдачи. Теперь работать надо.
> Работа SEO-шника — это не только понатыкать ссылок, да испоганить все тексты, как стало принято думать.
Очевидно! Именно по этому я и пишу, о том, что изучение поведения _живого_ юзера на сайте — наивернейший способ выяснить популярность сайта и его качественные характеристики.
По моим личным ощущениям, Яндекс делает все, чтобы продать побольше своего директа, занижая эффективность работы SEO-шников. Это ближе всего к главной цели, учитывая все аргументы, мотиваторы и т.п.
Что касается качества выдачи, здесь Яндексова мечта — Яндекс.тулбар. Именно благодаря этой штуке можно однозначно оценить действия пользователя и его хотелки и приоритеты. Не даром они недавно купили стартап, который отслеживает действия пользователя на сайте. Метрика, как вы сами написали около 8% сайтов. Именно поэтому они активно продвигают как метрику, так и браузеры со своим тулбаром, даже на флэшках…
Через ссылку — зло.
Через реестр — вполне себе живой вариант, если бы софт работал внятно. Это сравнимо с вариантом, если в линукс монтировать разные разделы под /var /usr /home и т.д. Там на работоспособность софта это никак не влияет :)
Можно расколотить все много мелких таблиц с одинаковыми ключами, либо писать пары «ключ/значение», где значение структурировано как то другим способом (CSV, XML...)
Мне кажется скоро, у них большую долю рынка откусят планшетники, когда дешеветь начнут. Одно толь то, что им не нужна дополнительная подсветка, уже плюс. Кроме того, если есть планшетник, руки к читалке уже не тянутся. Это из практики.
Хочется добавить…
Много сказано про типизированность данных в таблицах. mishinoleg, прав про рост кода в самом приложении. Все приводит к тому, что можно назвать, _самостоятельной реализацией части функций СУБД в своем коде под конкретную задачу_. (выделил подчеркиванием, к сожалению тэги недоступны)
В целом, могу из собственной практики сказать, что нормализация таблиц, по своей сути, близка, к тому, чтобы стать «хранилищем». Достаточно перестать использовать в запросах «join» и начать делать это руками в коде. Последнее, приведет к тому, что вы будете компоновать данные из таблиц наиболее оптимальным для вашей задачи способом. А это скажется на производительности. По сути, таблица в обычной базе с Primary Key и Blob-ом или длинной строкой, вполне может служить таким хранилищем, как ключ/значение. Учитывая наработки в движках SQL, запросы с выборкой по «основному ключу» врятли смогут быть уделаны различными свежими API. Скорее всего, они все таки выиграют.
Все что я хочу сказать, что если использовать реляционную базу просто, не нагружая ее семистраничными запросами, а нормализовав, реализовать большую часть математики и логики на уровне приложения, можно добиться и производительности и масштабируемости.
А вот если бы расписали иерархическую модель данных или сетевую… да еще бы нашли софт, который умеет с этим работать… совсем бы интересно было.
К слову сказать, иерархическая модель очень схожа с XML-структурой.
сотни тысяч записей в сутки, не считая пиковых нагрузок и постоянного роста абонентской базы.
Главная страница, безусловно, для 90% посетителей — первая страница, которую они загружают. Однако она далеко не единственная.
В данном топике я вижу, что люди постарались и кастомизировали лицо сайта под различные устройства с их различным разрешением и свойствами. Это хорошо. А вот то, что это сделало одно подразделение компании, говорит о том, что другие сервисы системы, если и оптимизируют что то, то уже на свой лад. Без унификации. Хоть малейшее отличие в подходах, но будет. Итог — пользователь будет теряться и привыкать к тому, что с одной стороны красное, с другой может оказаться фиолетовым.
Еще немного и будете делиться на подразделения «Команда sidebar-a главной страницы Яндекса», «Команда footer-a главной страницы Яндекса» и т.п.
Я считаю, что какую то часть влияния могут в ближайшем будущем оказать социальные сети, есть даже мысли, как это сделать, но пока ничего похожего я не видел и ресурсов сделать это самому, тоже нет.
«НЛО монетизирует и монетизирует».
Берем в руки микротайм и считаем в узловых точках скриптов время и считаем. В местах, где можно существенно сэкономить — экономим.
Я не могу сейчас уже привести примеры кода, но могу описать ситуацию, когда экономил на выводе больших массивов данных из базы. Удобно, например, при выводе детализаций по всякого рода аккаунтингу (трафик, звонки, смс и прочие тарифицируемые...). Такие данные характерны короткими справочниками с десятками записей и огромной таблицей CDR (собственно записей тарификации). Вот в таких ситуациях, чтение справочников целиком из базы в массив в памяти и использование этих массивов при выводе с одним простым запросом только к таблице CDR в базе, позволяется «разогнать» скрипт в сотни раз, по сравнению с решением в лоб — запросами с join-ами в базу данных.
Конечно, это скорее оптимизация СУБД, но средствами языка программирования. :)
Кроме того, много чего не умеет. У меня привычка в любой таблице иметь PK bigint unsigned auto_increment. Там такого не сделать. И видимо много чего… Это всего за первую минуту нашел.
Бурум, мне лично кажется удивительным, как ты до сих пор не открыл свой журнал. Чисто сетевой или глянцевый, не столь важно. Я уверен, что сколотить команду, тебе понадобится не больше недели, причем не на поиск, а на отбор лучших из желающих.
Чую за спиной наводящийся в затылок лазерный ствол НЛО :)
А некоторые мутируют, в рекламщиков, PR-шиков и т.п. Если влиять на выдачу поиска не получается (или становится дорого/невыгодно/не гарантировано), надо искать другие способы привлечения людей… конетекст, баннерная сеть, соц. сети, тематические площадки, агрегаторы предложений товаров и услуг и много-многое другое, на что не обращали внимание, когда достаточно было закупить миллиард ссылок и оказаться чуть ли не выше строки поиска в результатах выдачи. Теперь работать надо.
Очевидно! Именно по этому я и пишу, о том, что изучение поведения _живого_ юзера на сайте — наивернейший способ выяснить популярность сайта и его качественные характеристики.
Что касается качества выдачи, здесь Яндексова мечта — Яндекс.тулбар. Именно благодаря этой штуке можно однозначно оценить действия пользователя и его хотелки и приоритеты. Не даром они недавно купили стартап, который отслеживает действия пользователя на сайте. Метрика, как вы сами написали около 8% сайтов. Именно поэтому они активно продвигают как метрику, так и браузеры со своим тулбаром, даже на флэшках…
Через реестр — вполне себе живой вариант, если бы софт работал внятно. Это сравнимо с вариантом, если в линукс монтировать разные разделы под /var /usr /home и т.д. Там на работоспособность софта это никак не влияет :)