Пол лучше определять по отчеству — славянские отчества у женщин кончаются на «а», у мужчин, напротив — никогда не кончаются на «а».
Писал лет 10 назад библиотеку склонений ФИО в родительный падеж, исключение — ФИО содержащие «оглы/кызы» — собственно оглы у мужчин, кызы — у женщин, так что тоже 100% попадание в пол.
По фамилии — такое-же правило, у женщин всегда «а», кроме несклоняемых фамилий. Но тут и человек не угадает по фамилии :-)
Так очевидно же — нарушение целостности дерева. В myisam транзакций нет, а любая операция с деревом затрагивает много строк. В итоге часть строк изменилась, часть нет.
Восстановили из бэкапа, таблицы перевели в InnoDB (база была по ошибке создана в MyISAM)
Тут мне кажется нет «хуже» или «лучше». Это как говорить — «пусть алгоритм неправильно делит на 5, но куда хуже если он будет неправильно делить на 6».
Алгоритм вставки тривиален, удаления — тоже. Самый неприятный — произвольное перемещение — но все в пределах арифметики. Правильность реализации нужно контролировать ну никак не ключами.
Реальную проблему видел один раз — когда такое дерево положили в MyISAM :-)
В Closure Table точно так-же легко вставить ссылочно-правильные данные, но логически бессмысленные данные например сделать цикл, сославшись на родителя как на ребенка.
Нужно изучить на практике, идея интересная, но мне лично напоминает Materialized Path вынесенный в отдельную таблицу.
Я может и заблуждаюсь, но не понимаю в чем тут проблема.
Структура таблицы Nested Sets
id — первичный суррогатный ключ (автоинкремент)
left — левая граница
right — правая граница
level — уровень вложенности (кэшированное значение, можно пересчитать)
field1 — поле данных 1 (все поля данных можно спокойно вынести в отдельную таблицу, если хочется)
field2 — поле данных 2
…
fieldN — поле данных N
Если нужно сослаться на элемент дерева — ссылаемся на значение id
В чем проблема-то? Где тут нарушение ссылочной целостности? Приведите возможный сценарий.
Целостность данных структуры как вы правильно заметили обеспечивает атомарность транзакций.
А зачем, простите их использовать как внешние ключи?
На что им ссылаться? Это же данные о структуре дерева, чем они от других данных-то отличаются?
Для ссылок НА ветку дерева, у каждой строки имеется первичный ключ, т.к. естественного ключа нет — используется суррогатный — автоинкремент например. Хотя на практике для первичного ключа сейчас всегда используют суррогатные ключи даже при наличии естественного.
Почему это не обеспечивают ссылочную целостность?
Точно так-же используются суррогатные (автоинкрементные) ключи для ссылок.
Целостность данных обеспечивается транзакциями, нет никакой разницы между методами (ну если только не MYSQL/MyISAM использовать)
Для работы с «уровнями» дерева обычно их обычно кэшируют в отдельном поле LEVEL.
Ну связи можно спокойно отделить в любом подходе, отдельно хранить таблицу данных, отдельно — таблицу связей.
Для Nested Sets легко писать запросы к иерархии. Например полуоткрытое дерево можно одним запросом получить.
И самое главное что их легко визуализировать, нарисовали дерево, затем обвели «облачком» те узлы что нужно получить — и стали понятны условия запроса.
Опыт показал что иерархические данные обычно очень редко меняются, но часто запрашиваются. А в этом случае Nested Sets рулят и бибикают, по скорости работы выборок им нет равных. Да и запросы как ни странно выходят проще и нагляднее, даже в случае сложных выборок.
Заниматься бизнесом я не умею, поэтому остаюсь учредителем/совладельцем и не занимаясь оперативным управлением.
Чтобы реализовать ту или иную идею — нужно искать партнеров прежде всего.
«Достаточно большой» — это не нефтяная компания, но и не ларек :-) Доход от бизнеса не так стабилен как зарплата, его может не быть годы после запуска проекта, потому что вся прибыль вкладывается в развитие. Проект может «не взлететь», да много каких причин может быть.
Вы почему-то ставите вопрос ребром — «или/или», для меня он не так стоит — можно заниматься всем ;-)
Основная так и остается основной, хобби-проекты поэтому и хобби.
Это же вопрос в духе «Вам что больше нравиться — мороженное или пирожное?». Нравиться заниматься всем чем занимаюсь.
Основная работа дает стабильность, возможность разрабатывать и эксплуатировать сложные системы, использовать разнообразное и достаточно дорогое железо.
Хобби-проекты дают возможность отвлечься, развиться в другой области, не связанной с основной, увеличивают возможности само-реализации.
Сам нахожусь с похожей ситуации, но никакого драматизма не вижу.
Параллельно основной работе создал несколько хобби-проектов, некоторые из которых превратились в достаточно большие бизнесы.
Постоянно занимаюсь чем-то новым — чем дальше в лес, тем толще партизаны :-)
Когда начали закрадываться сомнения в профессиональном уровне (проекты технически обычны: php/mysql) решил поупражняться в чем-то новом — начал изучать Scala, прочитал пару книг, легко прошел курс progfun на Coursera (c максимальной возможной оценкой)
Понял что уровень мой более чем достаточен и продолжил заниматься тем, что считаю нужным — рефлексировать некогда :-)
Собственно как произошло с лошадьми, когда-то массовое умение ездить на лошади превратилось в дорогостоящее развлечение и отчасти спорт. Наверняка прадедушки ворчали, что на машине ездить — это не то удовольствие что на вороном…
Так и в WIKI тоже мнение, там обобщенные данные, практика использования конкретных девайсов может отличаться.
Да и TRIM это просто помощь алгоритму сборки мусора, если данные в виде архива с дедупликацией — может больше вреда быть, чем пользы — от конкретных данных сильно зависит.
«Бунша» — несклоняемая фамилия, поэтому по одной фамилии определить нельзя никак.
Писал лет 10 назад библиотеку склонений ФИО в родительный падеж, исключение — ФИО содержащие «оглы/кызы» — собственно оглы у мужчин, кызы — у женщин, так что тоже 100% попадание в пол.
По фамилии — такое-же правило, у женщин всегда «а», кроме несклоняемых фамилий. Но тут и человек не угадает по фамилии :-)
Восстановили из бэкапа, таблицы перевели в InnoDB (база была по ошибке создана в MyISAM)
Алгоритм вставки тривиален, удаления — тоже. Самый неприятный — произвольное перемещение — но все в пределах арифметики. Правильность реализации нужно контролировать ну никак не ключами.
Реальную проблему видел один раз — когда такое дерево положили в MyISAM :-)
Нужно изучить на практике, идея интересная, но мне лично напоминает Materialized Path вынесенный в отдельную таблицу.
Тогда запросы тривиальны, никаких группировок, просто WHERE parent.LEVEL = child.LEVEL — 1
Структура таблицы Nested Sets
id — первичный суррогатный ключ (автоинкремент)
left — левая граница
right — правая граница
level — уровень вложенности (кэшированное значение, можно пересчитать)
field1 — поле данных 1 (все поля данных можно спокойно вынести в отдельную таблицу, если хочется)
field2 — поле данных 2
…
fieldN — поле данных N
Если нужно сослаться на элемент дерева — ссылаемся на значение id
В чем проблема-то? Где тут нарушение ссылочной целостности? Приведите возможный сценарий.
Целостность данных структуры как вы правильно заметили обеспечивает атомарность транзакций.
На что им ссылаться? Это же данные о структуре дерева, чем они от других данных-то отличаются?
Для ссылок НА ветку дерева, у каждой строки имеется первичный ключ, т.к. естественного ключа нет — используется суррогатный — автоинкремент например. Хотя на практике для первичного ключа сейчас всегда используют суррогатные ключи даже при наличии естественного.
Точно так-же используются суррогатные (автоинкрементные) ключи для ссылок.
Целостность данных обеспечивается транзакциями, нет никакой разницы между методами (ну если только не MYSQL/MyISAM использовать)
Для работы с «уровнями» дерева обычно их обычно кэшируют в отдельном поле LEVEL.
Для Nested Sets легко писать запросы к иерархии. Например полуоткрытое дерево можно одним запросом получить.
И самое главное что их легко визуализировать, нарисовали дерево, затем обвели «облачком» те узлы что нужно получить — и стали понятны условия запроса.
Чтобы реализовать ту или иную идею — нужно искать партнеров прежде всего.
«Достаточно большой» — это не нефтяная компания, но и не ларек :-) Доход от бизнеса не так стабилен как зарплата, его может не быть годы после запуска проекта, потому что вся прибыль вкладывается в развитие. Проект может «не взлететь», да много каких причин может быть.
Вы почему-то ставите вопрос ребром — «или/или», для меня он не так стоит — можно заниматься всем ;-)
Это же вопрос в духе «Вам что больше нравиться — мороженное или пирожное?». Нравиться заниматься всем чем занимаюсь.
Основная работа дает стабильность, возможность разрабатывать и эксплуатировать сложные системы, использовать разнообразное и достаточно дорогое железо.
Хобби-проекты дают возможность отвлечься, развиться в другой области, не связанной с основной, увеличивают возможности само-реализации.
Да и потом — знаешь GIT — значит понимаешь любую SCM.
Параллельно основной работе создал несколько хобби-проектов, некоторые из которых превратились в достаточно большие бизнесы.
Постоянно занимаюсь чем-то новым — чем дальше в лес, тем толще партизаны :-)
Когда начали закрадываться сомнения в профессиональном уровне (проекты технически обычны: php/mysql) решил поупражняться в чем-то новом — начал изучать Scala, прочитал пару книг, легко прошел курс progfun на Coursera (c максимальной возможной оценкой)
Понял что уровень мой более чем достаточен и продолжил заниматься тем, что считаю нужным — рефлексировать некогда :-)
function array_column($arr, $col)
{
if (is_array($col) || !is_array($arr)) return array();
$f = create_function('$e', 'return is_array($e) && array_key_exists("'.$col.'",$e)? $e["'. $col .'"]: null;');
return array_map($f, $arr);
}
Купил бы не задумываясь PDF для чтения на iPad.
Да и TRIM это просто помощь алгоритму сборки мусора, если данные в виде архива с дедупликацией — может больше вреда быть, чем пользы — от конкретных данных сильно зависит.