Я же вроде объяснил, что $150 снимаются не дополнительно, а предварительно.
Т.е. если Вы заказали ноутбук за 260 долларов, то в момент заказа с кредитки будет снято 150 долларов, а в момент отправки его почтой - еще $110.
$150 - это всего лишь предоплата, а полную стоимость ноутбука снимут с баланса карты уже после его отгрузки.
А non-refundable - это на случай, если поставки ноутбуков задержатся.
Кстати, странная политика. Настораживает. Создается такое чувство, что реальная поставка произойдет не раньше ноября.
Моё мнение - лучше подождать, тем более что я не вижу в этом устройстве ничего такого, за что стоило бы заплатить $400. Это уже цена немного б\у 13" модели с центрино, 1Gb памяти, hdd на 80Gb и дисплеем высокого разрешения - чем не "gate в мир Web" ?
Я знаком и работал только с таким типом масштабирования, когда существует несколько полных копий DB на нескольких машинах и в зависимости от загруженности серверов циска адресует запрос на наименее загруженный. Как обновляется информация между серверами - не в курсе. Но быстро. В таком случае работают все джойны и прочее.
Держать одно соединение к DB всегда эффективнее чем несколько. (а в некоторых языках вовсе придется по очереди к серверам подключаться).
Когда делится одна таблица - это какая-то недораспределенная модель, необходимо центральный сервер, который знает что и где лежит. Или я опять не понял ? :)
Вобщем, я уже говорил - я не DBE. Хотите - объясните, не хотите - не пинайте, пожалуйста, я высказываю только свои мысли. :)
Джойны, конечно же, будут работать долго и неправильно в том случае, если неверно спроектирована структура данных или неверно настроены индексы (о них вообще нельзя забывать).
Для примера, был у меня один проект на доделке и оптимизации (система управления бизнесом), где в сутки генерировалось порядка 10-20 тысяч строк в две таблицы логов, выборки из этих таблиц делались ежедневно, кроном, который вызывал скрипт, запросы все были с джойнами, занимало это около 10 минут (суммарно обрабатывалось около 1 миллиона записей - из двух таблиц логов, каждая таблица по 4-5 миллионов записей и таблиц пользователей/вспомогательных таблиц, уже точно не помню сути, но минимум 5-7 таблиц участвовали в выборке).
После правильной расстановки индексов время этой выборки сократилось до 0.8 секунды и решено было кнопочку "сгенерировать статистику" перенести в вэб-интерфейс. Это при том, что изначально неверная структура БД переработана не была.
Есть места где необходимо перезагрузить страницу (загрузить ее по другому адресу), есть места где это лишнее. Даже на хабр посмотрите - 90% активных элементов на странице вызывают ajax.
Да, я абсолютно согласен. Но это уже частное решение, когда проект был криво разработан и криво функционировал до того момента, когда настала необходимость оптимизации.
Если БД построена верно - можно не бояться, а напротив, активно пользоваться джойнами там, где это нужно.
Всё минусуете и минусуете. ;)
А я, к сожалению, не могу.
Спорить не станете судя по всему по той причине, что не сможете объяснить чем генерация JSON по выборке из одной таблицы/единственного целевого набора таблиц будет медленней обновления всей страницы, где добавятся запросы к бд и обработчики/обращения в кэш для всех функциональных блоков страницы.
Я не возражаю против правильности проектирования БД и считаю все описанные тезисы проектирования абсолютно верными, более того я считаю что этим должен заниматься отдельный DBE, который курил все тонкости этого дела.
Я всего лишь отметил, что джойн всегда быстрее двух последовательных запросов, на каком бы уровне они не выполнялись - бд или скрипта. А спроектировать базу таким образом чтобы ни для одной выборки не требовалось объединять данные как минимум из двух таблиц - нереально.
Мне кажется, мы с вами говорим просто о разных вещах.
Джаваскрипт и аякс всё-таки весьма существенно разгружают сервер, начиная с траффика и заканчивая нагрузкой на сервер вследствии уменьшения количества операций при обновлении единственного блока страницы.
Другое дело, что он не всегда уместен.
А без join, view и прочих "прелестей" никакого серьезного проекта не построить вообще. Имхо.
1. Время генерации слишком большое. Действительно, СЛИШКОМ. Оптимальное время генерации для среднего сайта - около 0,05-0,1 с. Это без кеширования. Не найдейтесь что на мощном сервере будет работать быстрее, особенно если возлагаете настройку сервера на хостера.
2. Сисадмина (можно не постоянного, а "по вызову", главное - грамотного и адекватного) и SEOшника, желательно еще на этапе проектирования.
Всё остальное, имхо, зависит от сути и направленности проекта.
Да, кстати такая же проблема. Когда попытался добавить место работы адрес не сохранился, а вот адрес места жительства получил пометку "работаю".
Рано, имхо, выпустили они его в люди.
Сразу после получения вышеописанного глюка мне стало неинтересно и я закрыл страницу. :)
Плюс - очень сильно разочаровала не проработанная украина. Как минимум областные центры добавить - не такая большая сложность.
Судя по всему у гугла странно работает локализация и названия шрифтов находятся в локализируемом массиве. Для остальных названий просто не нашлось перевода в массиве подстановок..
Но собственно это так.. Попытка найти смысл. :)
Скорее - потому что так захотелось разработчику.
Не обязательно должен быть смысл в вещах.
Скорее уж ультрамобильный тонкий клиент.
Т.е. если Вы заказали ноутбук за 260 долларов, то в момент заказа с кредитки будет снято 150 долларов, а в момент отправки его почтой - еще $110.
$150 - это всего лишь предоплата, а полную стоимость ноутбука снимут с баланса карты уже после его отгрузки.
А non-refundable - это на случай, если поставки ноутбуков задержатся.
Кстати, странная политика. Настораживает. Создается такое чувство, что реальная поставка произойдет не раньше ноября.
Моё мнение - лучше подождать, тем более что я не вижу в этом устройстве ничего такого, за что стоило бы заплатить $400. Это уже цена немного б\у 13" модели с центрино, 1Gb памяти, hdd на 80Gb и дисплеем высокого разрешения - чем не "gate в мир Web" ?
не "четырёхпалый", а всё-таки "четырёхлапый", наверное. :)
А по сути, что-то мне давно кажется что цены на такие игрушки слишком завышены.
Держать одно соединение к DB всегда эффективнее чем несколько. (а в некоторых языках вовсе придется по очереди к серверам подключаться).
Когда делится одна таблица - это какая-то недораспределенная модель, необходимо центральный сервер, который знает что и где лежит. Или я опять не понял ? :)
Вобщем, я уже говорил - я не DBE. Хотите - объясните, не хотите - не пинайте, пожалуйста, я высказываю только свои мысли. :)
Дробление БД, имхо, имеет смысл только в том случае, когда самостоятельный ресурсоемкий блок выносится в отдельный модуль/приложение.
А вообще существует множество других методов.
Для конкретизации - рекомендую посмотреть на схемы работы Wikipedia, Livejournal и почитать о методах кластеризации серверов и приложений.
Я не DBE, тонкостей всех не знаю, не хочу позориться. :)
Да, бывает всякое, но это уже называется тюнингом.
Generally, умная модель базы данных + джоин - это правильно.
Для примера, был у меня один проект на доделке и оптимизации (система управления бизнесом), где в сутки генерировалось порядка 10-20 тысяч строк в две таблицы логов, выборки из этих таблиц делались ежедневно, кроном, который вызывал скрипт, запросы все были с джойнами, занимало это около 10 минут (суммарно обрабатывалось около 1 миллиона записей - из двух таблиц логов, каждая таблица по 4-5 миллионов записей и таблиц пользователей/вспомогательных таблиц, уже точно не помню сути, но минимум 5-7 таблиц участвовали в выборке).
После правильной расстановки индексов время этой выборки сократилось до 0.8 секунды и решено было кнопочку "сгенерировать статистику" перенести в вэб-интерфейс. Это при том, что изначально неверная структура БД переработана не была.
Есть места где необходимо перезагрузить страницу (загрузить ее по другому адресу), есть места где это лишнее. Даже на хабр посмотрите - 90% активных элементов на странице вызывают ajax.
Если БД построена верно - можно не бояться, а напротив, активно пользоваться джойнами там, где это нужно.
А я, к сожалению, не могу.
Спорить не станете судя по всему по той причине, что не сможете объяснить чем генерация JSON по выборке из одной таблицы/единственного целевого набора таблиц будет медленней обновления всей страницы, где добавятся запросы к бд и обработчики/обращения в кэш для всех функциональных блоков страницы.
Я не возражаю против правильности проектирования БД и считаю все описанные тезисы проектирования абсолютно верными, более того я считаю что этим должен заниматься отдельный DBE, который курил все тонкости этого дела.
Я всего лишь отметил, что джойн всегда быстрее двух последовательных запросов, на каком бы уровне они не выполнялись - бд или скрипта. А спроектировать базу таким образом чтобы ни для одной выборки не требовалось объединять данные как минимум из двух таблиц - нереально.
Мне кажется, мы с вами говорим просто о разных вещах.
Другое дело, что он не всегда уместен.
А без join, view и прочих "прелестей" никакого серьезного проекта не построить вообще. Имхо.
2. Сисадмина (можно не постоянного, а "по вызову", главное - грамотного и адекватного) и SEOшника, желательно еще на этапе проектирования.
Всё остальное, имхо, зависит от сути и направленности проекта.
Рано, имхо, выпустили они его в люди.
Сразу после получения вышеописанного глюка мне стало неинтересно и я закрыл страницу. :)
Плюс - очень сильно разочаровала не проработанная украина. Как минимум областные центры добавить - не такая большая сложность.
Но собственно это так.. Попытка найти смысл. :)
Скорее - потому что так захотелось разработчику.
Не обязательно должен быть смысл в вещах.