Если сильно утрировать, то по правилам яда если кто-то послал Вам денег, они как бы не Ваши, а пославшего, просто Вы можете ими распоряжаться.
По сути если Вы Вася, а денег послал Вам Петя, то очень грубой аналогией из оффлайн жизни будет чек от имени Пети, обналичить который имеет право любой предъявитель. При том обратите внимание, если Вы предъявите для обнала этот чек в банк, когда на счету у Пети уже нет денег или он аннулировал свой чек по звонку в банк, то это именно Вы попали и остались без денег. Заявление на возврат в яндекс это и есть по сути аннулирование чека, а возможность для Васи сопротивляться этому аннулированию это просто бесплатный бонус по принципу "Вася прямо в момент звонка Пети оказался в банке".
И именно вследствии этой точки зрения яндекс не может вернуть "другие" деньги в том же размере. Т.к. "другие деньги", это деньги по другому чеку, а яндекс не возвращает деньги, он аннулирует чек.
Обратите внимание, мы не защищаем подобную точку зрения, мы ее просто излагаем, при этом не вполне будучи согласными с ее правильностью "по понятиям".
Просьба не придираться к "аннулированию" и "чекам", это просто ближайшая аналогия из оффлайна. Если внимательно почитать яндексовские соглашения, то можно увидеть что аналогия в целом верная, но нам сейчас откровенно лениво подводить подробную под это базу.
Шанс реально есть. Всё зависит от юристов и судьи. Подобная трактовка законов ядом не однозначна на самом деле.
Для оплаты ядом напрямую описания в открытом виде нет. Они его присылают после подключения магазина как юридического лица. А как обычный физик Вы платежи принимать не имеете права, поэтому и инструкция Вам не нужна.
Можно подключать через ПЦ типа робокассы, там все на уровне ВМ и примерно аналогично.
То что он профессиональный - не согласны, обычный бытовой моник S-IPS (даже не UX серии), профессиональные это несколько совсем другое.
По цветопередаче будет лучше чем TN, но смотрите лампы, равномерная ли подсветка, все ли живы, иначе смысла нет. Опять же, цветопередача S-IPS востребована если Вы редактируете фотографии для печати в типографии, для ворда, интернета, бытовых фоток, фильмов и игр TN за глаза и за уши, s-ips это оверкилл откровенный... а для текста TN даже лучше.
По цене - судя по http://shop.ebay.com/i.html?_kw=nec&_kw=2070 - дороже 9 тысяч в россии никак не должен стоить.
p.s.: У самих матовый tn acer 24" 1920х1200 купленный год назад за 8 тысяч где-то, при чем купленный без ограничений по бюджету, при тщательном выборе в магазине и в сравнении с другими мониками (включая в выбор маковские мониторы). Довольны как слоны и менять не собираемся. Советуем зайти в ближайший лабаз с хорошим выбором моников (главное что бы матовые были) и просто посмотреть надо ли Вам s-ips в принципе.
Нет смысла.
Разрешение по современным меркам унылое.
2-летний ЖК монитор - уже могут начинаться проблемы с лампами.
Если конечно совсем нет денег что бы купить новый... но если монитор не для фотошопа покупается, то лучше купить современный TN, чем старый s-ips - для "обычных" нужд будет нисколько не хуже. Не ведитесь особо на антипиар TN матриц, если Вы сидите перед монитором, а не "где-то сбоку", то отличия по углам обзора Вас не коснутся, а по цене отличия существенны. Плюс для текста на самом деле TN даже лучше...
Это скукожит Вашу таблицу в 0
<title>Высота ячейки</title><style>td {height:0px;line-height:0px;font-size:0px;}</style></head><body><table width="500" border="0" cellspacing="0" cellpadding="0" bordercolor="#0000FF"><tr><td> </td><td> </td></tr><tr><td> </td><td> </td></tr></table></body></html>
Высоту в 0, ибо очевидно.
Бордер в 0, ибо очевидно.
Размер фонта в 0, ибо в некоторых браузерах это "квадратный" пробел определённой высоты.
line-height - см. про размер фонта.
Дальше играйтесь этими параметрами с целью добиться нужного эффекта. Обязательно проверяйте в FF и IE, т.к. именно с высотой "пустых" мест у них есть определённые различия.
Miracle,
Обратите внимание при анализе способов вот на какой момент.
Базовый это просто рут-чайлд, универсальный способ для всего.
За универсальность Вы платите некоторой усложненностью при построении запроса на выборку (как бы то ни было но select * from cat where subroot in (2,3) несколько проще чем запрос из нескольких джоинов) и некоторой замедленностью оной (прямая выборка под ключам, против хитроджоина или кучи запросов на выборку).
Именно поэтому используют Materialized path например или nested sets, а не просто так:)
Materialized path в текстовом поле по сути просто кэширование, разнеся на 3 (2? смотря что там под 3 уровнями подразумевается вложенности. ) отдельные целочисленные поля Вы улучшите размер таблицы и скороть оной (по сути то что мы предложили, это просто легкий вариант MP).
Поэтому если у Вас реально вложенность ограниченная, то подумайте стоит ли Вам охватывать неограниченные просторы.
И еще момент. Хитроджоин при выборке из рут-чайлд он псевдохорош в плане реализации идеи неограниченной вложенности. Потому что когда речь заходит о действительно хорошем уровне вложенности (не 3), то рут-чайлд или кладет мускул при хитроджоине или Вы начинаете генерить кучу запросов (что бы не хитроджоинить кучу уровней).
Впрочем если у Вас задача какая-то совсем банальная, то рут-чайлд вполне сгодится, хотя бы с точки зрения привычности понимания для других программеров которые потом будут ковыряться в коде.
Если Вам нужен только один "параграф", то
~<div class="content">.*?<p>(.*?)</p>.*?<div class="footer">~si
Если несколько, то как ни странно самое простое побить текст изначально, по типу
list(,$text)=explode('<div class="content">',$text);
list($text,)=explode('<div class="footer">',$text);
и потом в результате искать уже все вхождения <p> приведённым Вами регом.
И наконец
Более правильно ~<p>(.*?)</p>~
Во первых .*? - с ограничителем жадности
Во вторых ~ как ограничитель позволит Вам не заниматься маразмом с прослэшиванием слэшей
Есть такая тема как materialized path. Это когда при использовании child/parent так же вводится чаровое поле, в котором хранится вся последовательность категорий вверх в виде 1/5/8, а так же иногда непосредственные дети в виде 3,6,10,2. При индексированности этого поля поиск получается очень быстрый любой степени точности. Просто тупо like-ом select cat from table where MP like '1/5%' - выберет все в 1/5 категории.
В Вашем случае, учитывая вложенность 3, есть еще более быстрый и разумный подход чем 1/5/8 чаровое поле, это создать 3 поля вида root subroot childofroot ну и так далее если нужна более глубокая вложенность. Затраты на хранение минимальны, будет небольшой гимор при апдейтах конечно (крошечный на самом деле по сравнению с нестед сетс допустим тем же), а скорость и простота выборок Вас приятно удивит (просто выборка вида select cat from table where `subroot`=5 выберет все в 5 категории).
Опять же, в отличии от прямого подхода child/parent тут в бонусах меньший риск зацикливания, когда потом в Ваш код полезет школолопрограммер:)
Если вы делаете маленькие простенькие проекты то Вы правы, тогда понятно откуда у Вас такие рассуждения. Однако в таком случае и обычный rand() не вызовет особых проблем:)
Тем не менее даже 256Мб-ная таблица не подарок в плане построения индексов или их частого апдейта, т.к. в результате Вы можете сэкономить на выборках меньше, чем потратить на индексы.
Наличие данных скрипт генерации обеспечит. А скрипт делающий выборку должен проверять их валидность и достаточность, в случае если Вам нужна актуальность.
Если Вам нужна абсолютно 100% актуальность, то никто не мешает поддерживать кэширующую таблицу актуальной в реалтайме, параллельными запросами в нее, это один черт почти всегда будет быстрее, чем мучать большую рабочую таблицу с избыточными данными.
Никто не умаляет важности применения Вами этих решений, мы просто привели универсальное и стандартное решение, которое изрядно и предсказуемо облегчает задачу с минимальными кровопотерями.
И в этих случаях ее обеспечивает лишь реалтайм апдейт кэширующей таблицы или скрипт выборки проверяющий валидность выборки.
Мы именно об этом.
Нам кажется мы достаточно доступно объяснили о чем мы говорили, поэтому из топика откланиваемся что бы не скатываться в пустую дискуссию, если будут еще вопросы - обращайтесь в личку, ответим.
Это достаточно распространенное заблуждение, что если индекс строится по smallint (допустим), то он построится за доли секунды, какого-бы размера база не была.
Построить (именно построить) бинарное дерево по одному полю, так же по нескольким полям в первую очередь стоит перебор всей исходной таблицы. И если у Вас таблица пару гигабайт, то хоть по полю smallint, хоть по варчар индексы у Вас строиться быстро не будут.
С апдейтами ситуация немного другая, но в целом перегружать основную рабочую таблицу лишними индексами это очень плохая идея. Создатели mysql не зря придумали alter table disable keys и советуют его применять в ряде случаев.
Учитывает, если это надо и если правильно ее построить. В таких случаях просто добавляется дополнительное поле, по которому идет выборка. Если Вы обратите внимание на задачу ТС, такое всего одно и оно простое.
Кроме того, существует такая вещь как избыточность. Финальная фильтрация идет с учетом полных данных, но выборка по ней будет быстрой, т.к. основывается на ИД. Если нужно в результате 10 ИД, можно запросить 20, а если не хватит, то выдернуть еще.
Вы поймите основную мысль - она в том, что бы минимизировать размер таблицы по которой ведется выборка случайных ИД. Размер при чем в первую очередь физический. А дополнительная идея в том, что бы не дергать основную таблицу лишний раз.
Актуальность данных, если она нужна, должна гарантироваться не скриптом который строит доп.таблицу, а скриптом который делает выборку.
В практических задачах актуальность данных не всегда критична, но если она нужна, читайте выше про финальную фильтрацию.
Может Вы просто не вникали в суть тех, что предлагаются?
Конечно, каждый случай достаточно индивидуален, но на практике (а не в бешенной абстрактной теории заточенной под доказательство невозможности) решений есть соразмерное количество.
