Если жмакнуть одну из этих кнопочек, то увидеть скрытый контент!

Tweet

Итак, какие бывают ошибки и как их можно отловить.

1. Самые простые и самые распространённые — это ошибки, связанные с чудным свойством php — динамической типизацией. Помимо того, что иногда просто упускаешь из виду, что там и в каком формате у тебя хранится, php сам подкидывает сюрпризы вида true при сравнении «qwerty» == 0 и другие чудеса автоматического приведения типов и подобные им брейнфаки.

Если точно известно место, где переменная перестает себя вести, как от нее ожидают, то я особо не мудрствую и ставлю var_dump(переменная). Если догадка подтверждается, то исправляем косяк и идем дальше.

Но не всегда получается определить точное место расхождения значения с ожидаемым. Расхождение это может быть зарыто глубоко в дебри кода, либо наоборот, находится на самом видном месте.

Так же бывает, что переменная меняет значение из-за нарушенной логики приложения. Например, присвоение идет внутри локальной видимости вложенной функции или неверно построенного цикла. Наружу передается не тот результат, который ждешь, хотя с виду все правильно. Просто не там открыл или закрыл скобку и все изменяется причудливым образом.

Такую красоту довольно трудно отловить руками, особенно в крупных приложениях. Поэтому лучше воспользоваться дебаггером. Во всяких умных книжках довольно часто пишут про APD, хвалят его, но дата его последнего релиза за 2004 год как-то меня настораживает. В багтрекере пишут, что под 5.3 не хочет он работать, у меня из груши не встал, поэтому я забил на него.

Трассировку скрипта можно сделать xdebug’ом. Он часто бывает установлен, но как модуль PHP, а для нормальной работы нужно, чтобы он стоял как Zend module.  По установке все итак расписано в нете, не буду повторяться.

Xdebug генерирует отчет, который показвает последовательно, кто, куда, зачем обратился. Есть специальные парсилки логов, но мне удобнее читать сырые отчеты, потому как в консоли особо красоту не получишь, а через веб я не умею отлаживать. Выдается вот такая красота:

3	67	0	0.013521	394468	drXdebugTraceFileParser->parseLine	1		/home/alex/tmp/trace.php	123	1	$line = '2\t3\t1\t0.000772\t328656\n'
4	68	0	0.013588	394584	explode	0		/home/alex/tmp/trace.php	149	2	'\t'	'2\t3\t1\t0.000772\t328656\n'
4	68	1	0.013630	395376
4	69	0	0.013666	395348	count	0		/home/alex/tmp/trace.php	150	1	array (0 => '2', 1 => '3', 2 => '1', 3 => '0.000772', 4 => '328656\n')
4	69	1	0.013716	395348
4	70	0	0.013757	395436	array_pop	0		/home/alex/tmp/trace.php	178	1	array (0 => '{main}', 1 => 'ini_set')
4	70	1	0.013800	395408
4	71	0	0.013823	395332	drXdebugTraceFileParser->addToFunction	1		/home/alex/tmp/trace.php	180	5	$function = 'ini_set'	$time = 4.3E-5	$memory = 236	$nestedTime = 0	$nestedMemory = 0
5	72	0	0.013900	395376	in_array	0		/home/alex/tmp/trace.php	194

Этого достаточно, чтобы проследить логику хода выполнения и отследить косяки. Забыл еще сказать, что xdebug можно подключать на лету. Обычно я выключаю и дебаггер и профайлер в php.ini, а в нужном скрипте просто включаю их вместе или по очереди через

ini_set('xdebug.default_enable', 1);
ini_set('xdebug.profiler_enable', 1);

Это быстро, не нужно никаких дополнительных телодвижений. Xdebug еще можно подключать на кучу разных IDE, даже вроде в денвере он есть.Таким нехитрым образом можно отловить большинство ошибок и невнимательностей в коде. Естественно, что изначально задуманную кривую логику так не исправить.

2. Второй тип ошибок гораздо сложнее отловить. Они также появляются вследствии зевков и невнимательностей, но проявляют себя не сразу, а по наступлению определенных условий. Например, время работы или количество итераций или появление определенного числа в арифметических операциях или наоборот, его непоявление.Еще ошибки могут возникать из-за изменений среды окружения, например форк апача завершил свою сессию и скинул скрипт или крон запускает что-то, что отъело всю память и скрипт просто не может запуститься.

Таких условий может быть множество, всех их обьеденяет одна черта — они не проявляются сразу при запуске, поэтому при анализе лога дебаггера ничего подозрительного выявить нельзя.

Тут приходит на помощь замечательная утилита — strace. Я одно время мучился с тем, что апач раз в 24 часа убивал свои потоки, а с ними и скрипты, из-под которых они были запущены. Так вот был настроен сервер. Нашли ошибку, когда подключились с другого терминала непосредственно к скрипту и слушали его через strace. Там и увидели, что скрипт ловит SIGTERM. Как использовать strace я уже писал. Позволяет исследовать реальную работу скрипта в реальном времени и видит все, что с ним происходит. Вывод можно перенаправить в файл и потом проанализировать. Еще есть схожая утилита, называет ptrace. Все они родные для nix систем. Некоторые чуваки с хабры используют для схожих целей сишный дебаггер. Кому в чем удобней…

3. Третий тип ошибок заключается в том, что память начинает резко утекать куда-то и нужно выяснить куда. Они также возникают из-за невнимательности или усталости и получаются чудеса типа файл инклюдится в бесконечном цикле или переменная набирает и набирает обьемиз-за того, что ее не обнулили предварительно.  Все это конечно можно отловить и через strace, но лучше использовать для этого профайлер xdebug’а.

Также этот способ следует использовать в целях профилактики, чтобы держать под контролем количество вызовов, открытий файлов и размеров переменных. Сам xdebug конечно не отдает все в удобноваримом виде, но под чтение его отчетов есть куча утилит. Я пользуюсь этим скриптом. Он выдает отчеты вида

function            #calls time memory time memory
------------------------------------------------------------
ini_set                  3 0.0002      584 0.0002      584
fix_string               1 0.0010      264 0.0009      184
xdebug_call_file         1 0.0001       48 0.0001       48
xdebug_call_function     1 0.0000       32 0.0000       32
var_dump                 1 0.0002        0 0.0002        0
xdebug_memory_usage      1 0.0000        0 0.0000        0
xdebug_call_line         1 0.0000        0 0.0000        0
{main}                   1 0.0018      480 0.0003     -368

Здесь уже можно отследить и вызовы  и время. Запускаю его обычно в конце работы, чтобы посмотреть, не напортачил ли я чего в коде. Также использую его при оптимизации для оценки результатов

Вот такие нехитрые способы, надеюсь, помогут спасти время и нервы при отладке скриптов. Если есть у кого свои методики — велкам в коменты, буду рад услышать.

P.S. Если кто знает, как завести APD под 5.3, отпишитесь плз!

P.P.S Тут вот чувак просто тру-самурай, целый квест прошел чтобы найти ошибку. Шрифт жесть.

Там строку 967 в файле php_apd.c надо закоментить и все заработает.

И чтобы сделать читалку логов, надо скомпиленную pprofp скопировать в /usr/bin и создать ссылку на php в /usr/local/bin/

На закуску.

• Проблемы с сериализацией массивов
• Класс для работы с сервисами сокращения ссылок
• Простой способ проверки процесса на существование

Что такое денормализация? Это намеренное внесение изменений в нормализованную схему бд, после которых она перестает соответствовать правилам НФ.

Для чего это делается? Основная цель — это увеличение производительности ценой увеличения избыточности, возможных коллизий, а также некоторым неудобством составления сложных выборок. 

Когда то давно я делал глупые сравнения — быстродействие бд и файлов на предмет чтения из них. Вся прелесть баз в том, что можно задать целую кучу критериев для выборки, чего в файлах сделать нереально. Естественно, база уступит в простом чтении файлу.

Но иногда базы имеют настолько сложную структуру, что при выполнении выборки перелопачиваются сотни тысяч строк кода и это сказывается на быстродействии. И если схема нормализованна, то запрос будет идти уже не к одной таблице, а ко многим (в зависимости от числа сущностей). Что в свою очередь, увеличит время выполнения запроса еще в N раз.

Вот в таких случаях идет под нож структура бд и все данные намерянно помещаются в меньшее число таблиц. Чаще всего так делают, когда к базе идут, в основном, запросы на чтение. Таким образом уменьшается число соединений между таблицами.

На закуску.

• Нормализация баз данных: третья нормальная форма
• Нормализация баз данных: вторая нормальная форма
• Нормализация баз данных: первая нормальная форма

Большинство из таких сервисов предоставяют бесплатный пробный доступ на несколько дней, но я искал полностью бесплатный вариант, пускай и не сильно функциональный.

Lumzy

Дают только 15 дней триала. Немного детский интерфейс, есть ночной вариант дизайна. Попробовал накидать форму, не смог поменять текст в текстовом поле. На том и закрыл его, не совсем он интуитивен.

Mockingbird

Крайне серьёзный онлайн-редактор с дизайном в стиле мака. Есть возможность сохранять, приглашать друзей для совместной работы. И просто отличный интерфейс, все понятно, все находится само собой. За 20 минут набросал концепт, впечатления от работы крайне положительные. Бесплатная версия дает 1 проект и 10 страниц. Для небольшой работы вместе вполне пригодится.

MockFlow

Еще один весьма неплохой редактор. Есть возможность импорта-экспорта, расшаривания. Весьма широкие наборы компоненты. И одна супер фича — есть пользовательская библиотека готовых шаблонов. Можно выбрать уже созданные кем-то шаблоны и заюзать их для своих целей. Есть ревизии для проектов. В халявной версии 4 страницы, 10 мегабайт хранилица и двое сотрудников для одновременного труда. Экспорт с водной маркой сервиса.Конкурент mockingbird.

На закуску.

• Ничего нет похожего на этот пост, он неповторим

Третья нормальная форма.

База данных будет находиться в третьей нормальной форме, если она приведена ко второй нормальной форме и каждый не ключевой столбец независим друг от друга. Если следовать процессу нормализации правильно до этой точки, с приведением к 3НФ может и не возникнуть вопросов. Следует знать, что 3НФ нарушается,  если изменив значение в одном столбце, потребуется изменение и в другом столбце.  В примере с форумом (рисунок вверху), проблем с приведением к 3НФ не возникнет, но можно рассмотреть как образец гипотетическую ситуацию, где это может произойти.

Возьмём, как образец, одиночную таблицу, которая хранит некую информацию о бизнес клиентах: имя, фамилию, телефон, адрес, город, штат, почтовый индекс и все в этом духе.  Такая таблица не будет находится в 3НФ, поскольку тут много полей будет взаимозависимо — улица будет зависеть от города, город от штата, почтовый индекс тоже под вопросом. Все эти поля будут подчинены друг другу, а не человеку, к которому относится эта запись.

Чтобы нормализовать такую базу, нужно создать по таблице для штатов, городов (с внешним ключом, ведущим в таблицу штатов) и для почтовых кодов. Все они будут ссылаться назад на клиентскую таблицу.

Если вы чувствуете, что все эти действия могут быть излишними, вы правы.  Честно, в верхних уровнях нормализации часто нет необходимости.  Смысл в том, что нужно стараться нормализовать базу данных, но иногда приходиться идти на уступки ради того, чтобы не допустить чрезмерного усложнения. Потребности приложения и структура данных в базе подскажут, насколько потребуется проводить процесс нормализации.

Как уже говорилось,  пример с форумом уже достаточно нормализован, но все равно опишем шаги для нормализации для третьей нормальной формы, показав как исправить пример с клиентами.

Чтобы привести базу к третьей нормальной форме, надо:

1. Определить, в каких полях каких таблиц имеется взаимозависимость. Как только что говорилось, поля, которые зависят больше друг от друга (как город от штата), чем от ряда в целом. В базе форума такой проблемы нет. Взглянув на таблицу сообщений, увидите, что каждый заголовок, каждое тело сообщения относится к своему message ID.

2. Создайте соответствующие таблицы. Если есть проблемный столбец в шаге 1, создавайте раздельные таблицы для него. Как города и штаты, в примере с клиентами.

3. Создайте или выделите первичные ключи. Каждая таблица должна иметь первичный ключ. Для примера с клиентами это будут city ID и state ID.

4. Создайте необходимые внешние ключи, которые образуют любое из отношений. В нашем примере нужно добавить state ID в таблицу городов и city ID в таблицу клиентов. Это свяжет каждого клиента с городом и штатом, где они живут.

Рассмотренная в качестве примера база данных с записями о клиентах, созданы две новых таблицы для хранения информации о городах и штатах.

Подсказки:

Вообще, можно было бы и не нормализовывать базу с клиентами до такой степени. Если оставить города и штаты в таблице клиентов, самое страшное, что могло бы случиться — если бы город изменил название, нужно было бы менять его во всех записях о клиентах, которые живут в этом городе. Но города редко меняют свои имена.

Несмотря на то, что имеются правила как нормализовывать базы данных, разные люди сделают это разными способами.  Проектирование баз данных допускает личные предпочтения и интерпретации. Важно, чтобы в базе не было явных нарушений нормальных форм, которые могут привести в дальнейшем к проблемам.

Нарушения правил нормализации

Убедившись, что база данных в 3НФ поможет гарантировать надёжность и жизнеспособность, не нужно полностью нормализовывать все базу, с которыми вы работаете. Перед тем, как использовать эти методы, имейте ввиду, что это может иметь долгосрочные разрушающие последствия.

Две основных причины, чтобы нарушить правила нормализации — удобство и быстродействие. Меньшим число таблиц проще управлять, чем большим. Кроме того, из-за более сложного характера, нормализованные таблицы более медленные для обновления, изменения и выдачи данных. Вкратце, нормализация это сделка между целостностью/расширяемостью и простотой/скоростью. С другой стороны, есть достаточно способов чтобы улучшить производительность базы данных, но не так много способов чтобы исправить повреждённые данные, возникшие из-за плохого дизайна структуры.

Практика и опыт подскажут, как сделать модель базы данных, но лучше совершайте ошибки пробуя нормальные формы, хотя бы до тех пор, пока не поймете принцип.

Ссылки:

1. Введение
2. Первая нормальная форма
3. Вторая нормальная форма
4. Вики о нормализации
5. Mysql Workbench — программа для проектирования баз данных

На закуску.

• Денормализация базы данных
• Нормализация баз данных: вторая нормальная форма
• Нормализация баз данных: первая нормальная форма

Вторая нормальная форма.

Для приведения таблиц ко второй нормальной форме (2НФ), приводимые таблицы должны быть уже в 1НФ. Нормализация должна проходить по порядку.

Теперь, во второй нормальной форме, должно быть соблюдено условие — любой столбец, который не является ключом (в том числе внешним), должен зависеть от первичного ключа. Обычно такие столбцы, имеющие значения, который не зависят от ключа, легко определить. Если данные, содержащиеся в столбце, не имеют отношения к ключу, который описывает строку, то их следует отделять в свою отдельную таблицу. В старую таблицу надо возвращать первичный ключ.

На рисунке выше и названия фильмов и имена актеров нарушают правила 2НФ (сами не являются ключами и не зависят от первичного ключа).

После всех преобразований, база данных с фильмами будет иметь минимум 4 таблицы.

Чтобы привести бд ко второй нормальной форме, потребовалось 4 таблицы. Режиссёры (directors), представлены в фильмах (movies) через внешний ключ director ID, фильмы в таблице фильмы-актёры (movies-actors) через movie ID, актеры через actor ID

Каждое имя режиссёра, название картины и имя актера хранится только один раз и все неключевые поля зависят от первичного ключа их собственной таблицы.

По факту, нормализация может быть утрированно названа процессом создания все новых и новых таблиц до тех пор, пока избыточность и повторения не будут полностью уничтожены.

Чтобы привести базу ко второй нормальной форме, надо:

Чтобы привести эту базу к 2НФ, нужно 3 таблицы минимум

• Определить все столбцы, которые не находятся в прямой зависимости от первичного ключа этой таблицы. На рисунке выше у таблиц users и forums нет первичного ключа. У таблицы messages первичный ключ — message ID, от которого зависят все остальные поля этой таблицы.
• Создаем необходимые поля в таблицах users и forums, выделяем из существующих полей или создаем из новых первичные ключи.
  

  Для каждой таблицы нужен свой первичный ключ

• Создаем внешние ключи и обозначаем их отношения между таблицами. Конечным шагом нормализации до 2НФ будет являться выделение внешних ключей для связи с ассоциированными таблицами. Первичный ключ одной таблицы должен быть внешним ключом в другой. На рисунке снизу показана связь между ключами трех таблиц. Поле user ID таблицы messages является первичным ключом поля user ID таблицы users.  Тип связи между ними — один ко многим. Один пользователь может оставить много сообщений, но у сообщения может быть только один пользователь. Такая же связь соединяет таблицы forums и messages через forum ID. У форума может быть много сообщений, но сообщение может находиться только в одном форуме.

Чтобы соотнести три таблицы, в messages добавлено два внешних ключа, ведущих на первичные ключи в своих таблицах

Подсказки:

• Другой способ приведения схемы к 2НФ — посмотреть на отношения между таблицами. Идеальный вариант — создать все отношения вида один-к-многим. Отношения вида многие-к-многим нуждаются в реструктуризации.
• Если взглянуть еще раз на таблицу movies-actors, то можно заметить, что она является промежуточной таблицей. Она превращает отношение многие-к-многим между movies и actors в один-к-многим. Можно вводить такие промежуточные таблицы, у которых все столбцы являются ключами. В таких таблицах не требуется свой собственный первичный ключ, поскольку он может быть комбинацией двух внешних ключей.
• Нормализованная должным образом таблица никогда не будет иметь повторяющихся рядов (двух и более рядов, значения которых не являются ключами и содержат совпадающие данные).
• Чтобы упростить нормализацию, помните, что при приведении к 1НФ вы ищете дубли горизонтально (дубли столбцов), а при приведении к 2НФ — вертикально (дубли рядов).

На закуску.

• Денормализация базы данных
• Нормализация баз данных: третья нормальная форма
• Нормализация баз данных: первая нормальная форма

Первая нормальная форма

Как писалось выше, нормализация — это приведение структуры бд в порядок в соответствии с несколькими правилами. Правилам нужно следовать точно, и приводить к формам нужно в порядке их следования.

Чтобы привести таблицу к 1НФ, нужно соблюсти два правила:

1. Атомарность или неделимость. Каждая колонка должна содержать одно неделимое значение.
2. Таблица не должна содержать повторяющихся колонок или групп данных.

Например, если таблица содержит в одном поле полный адрес человека (улица, город, почтовый код), не будет отвечать правилам 1НФ, поскольку будет содержать различные значения в одном столбце, что будет нарушением правила об атомарности. Или если бд содержит данные о фильмах и в ней есть столбцы актер1, актер2, актер3, также не будет отвечать правилам, поскольку будет иметь место повторению данных.

Начинать нормализацию следует с проверки структуры бд на совместимость с 1НФ. Все столбцы, которые не являются атомарными, должны быть разбиты на составляющие их столбцы. Если в таблице есть повторяющиеся столбцы, то им нужно выделить отдельную таблицу.

Чтобы привести таблицу к первой нормальной форме, следует:

• Найти все поля, которые содержат многосоставные части информации. На рисунке выше, поле message date содержит день, месяц, год и время, которое можно разбить на составные части, но в данном примере такая детализация даты не нужна.  Mysql может работать и с таким форматом — благодаря типу DATETIME. В этом примере разбито имя пользователя на имя и фамилию. Еще примерами неудачных решений могут быть поля, в которых хранятся сразу все телефоны человека (мобильный, рабочий) или его интересы (готовка, танцы).
• Те данные, которые можно разбить на составные части, нужно выносить в отдельные поля. На рисунке выше так разнесено полное имя на имя и фамилию.
• Выносите повторяющиеся данные в отдельную таблицу. В примере с форумом такой проблемы нет, поэтому возьмем в качестве примера таблицу, содержащую информацию о фильмах. Там есть несколько полей actor, которые являются повторяемыми. Повторяемые поля тут несут две проблемы. Если хранить информацию об актерах таким образом, то их число будет лимитировано числом таблиц. Даже если их будет 100, то все равно это будет пределом для некоторых фильмов. И вторая проблема — будет большое количество пустых(NULL) ячеек для большинства остальных записей, чего также следует избегать. Решением этой проблемы станет создание отдельной таблицы для актеров, куда будет заносится информация обо всех необходимых фильмах. Имена актеров также разбиты, чтобы соблюсти атомарность. Также в этой таблице присутствует свой первичный ключ, что является необходимым условием для нормализации.
• Дважды проверьте, все ли таблицы подходят под условия первой нормальной формы.

проблема избыточных полей

решение проблемы избыточных полей

Подсказки

• Простейший путь приведения к 1НФ — это пройтись глазами по всем столбцам. Проверьте каждый ряд на отсутствие повторения схожих данных и делимости.
• Разные источники трактуют процесс нормализации по своему, в основном более сухим, техническим языком. Более важен результат нормализации, а не повторение правил и умных слов.

Следующий пост будет посвящен второй нормальной форме — 2НФ.

На почитать

• Мой вводный пост о нормализации
• Вики о 1НФ Там же дано четкое определение атомарности.
  
• Сайт Мурманского технического университета

На закуску.

• Денормализация базы данных
• Нормализация баз данных: третья нормальная форма
• Нормализация баз данных: вторая нормальная форма

Задела глава про нормальные формы. Довольно мудрёную тему автор раскрывает в весьма доходчивой манере. На русском издания я не нашел, поэтому перевел эту часть книги. Обьем статьи довольно большой, поэтому я разобью на несколько постов. В этом будет вводная часть.

Вкратце, что такое нормализация. Большинство современных субд разработаны на основе реляционной алгебры, которая появилась раньше самих реляционных субд под авторством некого доктора Кодда. Он же вывел несколько правил, или форм, по упорядочиванию данных и их отношений. Всего таких форм 6 + две вне конкурса, Бойса-Кодда и доменно-ключевая.

На практике редко нормализуют дальше 3-ей нормальной формы. Поподробнее узнать обо всех нормальных формах и теории по ссылкам внизу поста.

Все примеры из книги показаны на бд для форума с обычной для форумов структурой — посты, авторы, время и т.п.

Вот так выглядит схема до преобразования.

Ключи

Ключи  являются составляющей частью нормализованных таблиц. Бывают двух видов — внешние и первичные.

Первичный ключ — это уникальный идентификатор, отвечающий следующим условиям:

1. Он должен иметь значение, не NULL.
2. Быть неизменным — значение ключа не должно меняться.
3. Иметь уникальное значение для каждой строки.

Внешние ключи — это ссылки на первичные ключи других таблиц, которые удовлетворяют условиям выше.

Для начала нормализации следует указать хотя бы один первичный ключ. В примере это будет message ID.

Для указания первичного ключа, надо найти поле, которое будет подходить под все три условия. Если такого поля нет, его надо создать. В идеале, поле должно иметь тип integer.

 Отношения

Отношения — это указатели, которые показывают, как соотносятся данные в одной таблице с данными в другой. Проще говоря, ссылка с одного столбца первой таблицы на другой столбец второй таблицы. Бывают трех видов — один-к-одному, один-к-многим, многие-к-многим.

Отношение один-к-одному означает что поле1 соотносится с полем2. Пример — у каждого человека свой номер паспорта. 1 человек- 1 паспорт. Тут отношение один-к-одному.

Один-к-многим указывает, что поле1 может соотносится как с полем2, так и с полем3, полемN… В книге приведён пример — у одного мужчины может быть много женщин и наоборот Автор юморист Один-к-многим самая распространённая связь между таблицами в нормализованных базах.

Отношение многие-к-многим бывает, когда нескольким значениям из одной таблицы соответствует несколько значений другой таблицы. Например, в категории блога может быть много постов, а у блога может быть много категорий. Еще такое отношение может встречаться в составных ключах. Такой связи следует избегать, поскольку она ведет к избыточности данных. В том-же вордпрессе категории и посты соотносятся через третью таблицу — wp_relationships.

На рисунке приведены условные обозначения всех трех отношений в нотации UML.

Создание структуры базы данных (схема) и отношений между таблицами можно ускорить, использую различные CASE-средства. В конце будет ссылка на mysql workbench, бесплатную кроссплатформенную программу.

На почитать:

• Нормальные формы на вики
• Основные приемы нормализации от мелкомягких. Кстати, это не далеко не первый годный материал, который я нашел у них в knowledge base. Туфту не пишут
• Аскетичный сайт с кучей теории по реляционным субд и реляционной алгебре
• Mysql Workbench

На закуску.

• Денормализация базы данных
• Нормализация баз данных: третья нормальная форма
• Нормализация баз данных: вторая нормальная форма

Но это не очень красивое решение. Очень запросов много + на переменные память расходуется. Проще использовать вложенные запросы, они же nested queries. Но тут возникает проблемка -  если вставлять  только данные из INSERT, то все ок, но если добавлять еще и какие-нибудь неизменные значения, то выдается Subquery returned more than 1 value.

Чтобы не обьяснять на пальцах — сама таблица B

CREATE TEMPORARY TABLE `B` (
  `status` TINYINT(4) NULL DEFAULT NULL ,
  `pair` TEXT NULL DEFAULT NULL ,
)
ENGINE = MyISAM
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;

Копируем из таблицы A и вставляем в B так

INSERT INTO `B` (`pair`)
            SELECT `pair` FROM `A` ORDER BY RAND() LIMIT 100;

Если поле status имеет неизменное значение, например 123, то просто вот так уже не вставить

INSERT INTO `B` (`status`, `pair`) VALUES (
            (SELECT `pair` FROM `A` ORDER BY RAND() LIMIT 100),
            123);

Не совсем красивое решение нашел

UPDATE `B` SET `status` = '123' WHERE 1=1;

Но хотелось бы в одну строку все заделать. Отпишитесь плиз в коментах, кто знает, как реализовать.

На закуску.

• Скрипт для тюнинга MYSQL
• MYSQL RAND(), как получить рандомную строку из БД
• Робкий tar )

Проблем может быть две — первая это включенная директива magic_quotes. Лечится примерно так -

(get_magic_quotes_gpc()) ? stripslashes(unserialize($variable)) : unserialize($variable);

За работу кода не отвечаю, но думаю мысль понятна.

Второй вариант, с которым втух я на несколько часов, это переносы строки. Если массив имеет в себе ячейку, в которой несколько строк, то он нифига не сериализуется взад, а выдаст false. Лечится убиванием \r\n

$str = preg_replace("/\n/", "", $str);
$str = preg_replace("/\r/", "", $str);

На закуску.

• Профилирование и отладка PHP скриптов
• Класс для работы с сервисами сокращения ссылок
• Простой способ проверки процесса на существование

Сама команда:

find . -type f -name "*.php" -exec wc -l {} +;

На закуску.

• Простой способ проверки процесса на существование
• Как узнать статус процесса по pid
• Организация бекапа на серверах