Но я вот не согласен с вами в основной мысли, которая красной нитью проходит через статью. Что развитие математики строится на «придумывании» абстракций и их исследовани. Вообще, цитирую — «возможность придумывать некоторые абстракции и утверждения и выводить из них непротиворечивые следствия» — это называется «аксиоматика». Это, безусловно, базовое понятие в математике. Но дело в том, что аксиоматика становится завершающим этапом создания какой-либо теории. Начинается же теория с обобщения знаний и поиска закономерностей.
Взять, к примеру, ту же геометрию. Изначально, как помним из курса средней школы, геометрия была уделом земледельцев. Использовалась для разметки и измерения полей. Со временем накопился какой-то багаж разрозненных сведений и приемов (т.е. знаний). Потом оказалось, что некоторые из этих знаний можно использовать в других ремеслах (в строительстве например). Далее эти знания абстрагировались и обобщились в теорию. И уже после всего этого некто Евклид описал аксоматику этой теории.
Вот кстати, возвращаясь к обучению. Мне кажется, что ноги невосприимчивости к математике растут из неправильного подхода к преподаванию. Почему-то при изучении любой теории она вводится с конца, т.е. с аксиом. На мой взгляд гораздо правильней в преподавании пройти весь путь развития теории, что б ее аксиомы стали очевидны сами собой. Для краткости можно сокращать некоторые незначительные шаги и тупиковые направления. Вобщем-то и ваше понятие, что «придумывают аксиомы, а по ним строят теорию» берется тоже отсюда.
Но что б добиться желаемого, пришлось полностью воспроизвести табличную структуру (я о значениях table и table-row). Так что об отдельных элементах говорить не приходится. Вообще, хорошо бы провести эксперимент.
Вот если б вся статья была написана с использованием table, tr и td, то статья в лучшем случае вызвала бы недоумение. А обсуждаемый код всего лишь подменяет названия тегов, сохранив и «квадратно-гнездовое» табличное мышление и все остальные прелести таблиц.
«Раздражающие» названия тегов в табличной верстке — не самый большой ее недостаток. А значение «table-cell» — позволяет из любого дива или лист-айтема сделать тд. Хотя стоп, я в этом не большой специалист. Лучше вообще в форме вопроса говорить — значение «table-cell» действительно делает из любого тега фактически ТД?
Уже не первый раз вижу упоминание «display:table-cell» на хабре. И вот вроде все красиво и хорошо, но одна маленькая заноза — а не становится ли от этого верстка фактически табличной?
Нет, не сам. Когда я слышал эту историю впервые, она была именно такой. Разумеется я не могу гарантировать ее достоверности. Немного ниже комментарий Nash'а (http://nash.habrahabr.ru/). Лучше сказать у меня не получится:
«Если бы не Эйнштейн в конце этой притчи, она не была бы так хороша ) И хотелось бы поспорить, предложить свою гипотезу, свои ответы... НО такая концовка меняет акценты, сбивает с толку. И хочется только написать: "Понравилось, спасибо!".
ps И абсолютно все равно, действительно ли это был Эйнштейн, и было ли это все на самом деле. На то она и притча.»
Спасибо! Про «пронумеровать без пропусков» пытался сказать в самом начале — «порядок следования записей не определен». Сейчас перечитывая, вижу, что действительно многие важные моменты упомянуты вскользь. Пока не знаю как их выделить, сохранив краткость… Подумаю.
Кстати, про деревья расскажите пожалуйста, а как их еще-то можно хранить? Просто действительно не знаю :)
В смысле, понимаю, что чисто бинарные деревья можно хранить ссылками на левое и правое поддерево. У произвольных деревьев можно хранить ссылку на «первого потомка» и на «брата». Знаком и с такой экзотикой, как «развертка дерева» (таблица живущая на триггерах и содержащая все пары «узел, предок»), что позволяет делать произвольные запросы по дереву, без использования ораклового «connect by prior». Но за всю практику никогда не доводилось использовать что-то отличное от простого parent_id.
Незачем им проектировать. Действительно, для проектирования, по-хорошему нужно интуитивно понимать смысл нормальных форм, отношений, целостности и непротиворечивости данных. Но так уж случилось, что я живу в том мире который есть, а не в том каким он должен быть по моим представлениям. И в этом мире чайники проектируют базы, а мне иногда приходится с ними сталкиваться. Причем нельзя сказать, что они мерзавцы и негодяи, эти чайники. Просто вот так сложилась ситуация, что им пришлось сделать то в чем они не компетентны. К счастью иногда, столкнувшись с противоречиями в проектировании, они обращаются к знакомым, читающим хабр, ну или ко мне лично (в случае моих знакомых чайников). Раньше мне приходилось объяснять азы теории в режиме онлайн-трансляции в аське. Теперь я просто дам ссылку на эту статью. Именно по-этому я сделал ее максимально краткой и с минимальных содержанием терминов.
Прочитайте первые отзывы. Иногда нам приходится сталкиваться с базами, содержащими таблицы названные в честь месяцев года и с 31-м полем (по кол-ву дней месяца).
Хабралюди, вы вообще предисловие-то прочитали?
Это и есть «пошаговая инструкция для чайников». Ни на что большее эта статья не претендует. Сковородку засуньте себе в… посудомойку. В рассматриваемом примере такая реализация дерева полностью оправдана.
Про трудность подбора гуида — оказался не прав. Его несложно было подобрать в достаточно древних способах генерации, сейчас он действительно неуязвим в этом смысле.
Но опять же считаю, что во многих системах такие меры безопасности избыточны. А если по подобранному ИД чужого заказа, можно его удалить не имея полномочий, эту проблему точно нужно решать не переходом на гуиды.
Если уж вдаваться в детали — вот таких «postanswer.php?userId=123» урлов стоит избегать в любом случае. ИД юзеров вообще не стоит светить вне зависимости от способа его генерации. ИД большинства других объектов — безобидны с т.з. безопасности. Что б далеко не ходить за примерами — посмотрите на этот сайт. ИД сообщения — число. А ИД вас, как пользователя, на сайте нигде нет.
Про преимущество генерации на стороне клиента отвечу вашими же словами — «экономия на семечках». Вставка новых объектов происходит как правило на порядок реже чем запросы по ним. Если идет непрерывный «поток вставки», обычно не требуется немедленно получать ИД. Ну а если уж требуется быстро и много «вставлять» и отдавать ИД, можно одним запросом «забронировать» сотню ИД и раздавать ее на клиенте.
Вот и википедия говорит, что «Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов» (http://ru.wikipedia.org/wiki/GUID)
Но я вот не согласен с вами в основной мысли, которая красной нитью проходит через статью. Что развитие математики строится на «придумывании» абстракций и их исследовани. Вообще, цитирую — «возможность придумывать некоторые абстракции и утверждения и выводить из них непротиворечивые следствия» — это называется «аксиоматика». Это, безусловно, базовое понятие в математике. Но дело в том, что аксиоматика становится завершающим этапом создания какой-либо теории. Начинается же теория с обобщения знаний и поиска закономерностей.
Взять, к примеру, ту же геометрию. Изначально, как помним из курса средней школы, геометрия была уделом земледельцев. Использовалась для разметки и измерения полей. Со временем накопился какой-то багаж разрозненных сведений и приемов (т.е. знаний). Потом оказалось, что некоторые из этих знаний можно использовать в других ремеслах (в строительстве например). Далее эти знания абстрагировались и обобщились в теорию. И уже после всего этого некто Евклид описал аксоматику этой теории.
Вот кстати, возвращаясь к обучению. Мне кажется, что ноги невосприимчивости к математике растут из неправильного подхода к преподаванию. Почему-то при изучении любой теории она вводится с конца, т.е. с аксиом. На мой взгляд гораздо правильней в преподавании пройти весь путь развития теории, что б ее аксиомы стали очевидны сами собой. Для краткости можно сокращать некоторые незначительные шаги и тупиковые направления. Вобщем-то и ваше понятие, что «придумывают аксиомы, а по ним строят теорию» берется тоже отсюда.
Уже не первый раз вижу упоминание «display:table-cell» на хабре. И вот вроде все красиво и хорошо, но одна маленькая заноза — а не становится ли от этого верстка фактически табличной?
«Если бы не Эйнштейн в конце этой притчи, она не была бы так хороша ) И хотелось бы поспорить, предложить свою гипотезу, свои ответы... НО такая концовка меняет акценты, сбивает с толку. И хочется только написать: "Понравилось, спасибо!".
ps И абсолютно все равно, действительно ли это был Эйнштейн, и было ли это все на самом деле. На то она и притча.»
Кстати, про деревья расскажите пожалуйста, а как их еще-то можно хранить? Просто действительно не знаю :)
В смысле, понимаю, что чисто бинарные деревья можно хранить ссылками на левое и правое поддерево. У произвольных деревьев можно хранить ссылку на «первого потомка» и на «брата». Знаком и с такой экзотикой, как «развертка дерева» (таблица живущая на триггерах и содержащая все пары «узел, предок»), что позволяет делать произвольные запросы по дереву, без использования ораклового «connect by prior». Но за всю практику никогда не доводилось использовать что-то отличное от простого parent_id.
Прочитайте первые отзывы. Иногда нам приходится сталкиваться с базами, содержащими таблицы названные в честь месяцев года и с 31-м полем (по кол-ву дней месяца).
Date tomorrowDate() {
Thread.currentThread().sleep(24 * 60 * 60 * 1000);
return new Date();
}
Это и есть «пошаговая инструкция для чайников». Ни на что большее эта статья не претендует. Сковородку засуньте себе в… посудомойку. В рассматриваемом примере такая реализация дерева полностью оправдана.
select setval('seq_name', currval('seq_name') + 100) Postgres
Про трудность подбора гуида — оказался не прав. Его несложно было подобрать в достаточно древних способах генерации, сейчас он действительно неуязвим в этом смысле.
Но опять же считаю, что во многих системах такие меры безопасности избыточны. А если по подобранному ИД чужого заказа, можно его удалить не имея полномочий, эту проблему точно нужно решать не переходом на гуиды.
Просто в большинстве случаев из контекста понятно какие объекты нужно получать. А здесь да — подразумевается, что могут быть «вперемешку».
Про преимущество генерации на стороне клиента отвечу вашими же словами — «экономия на семечках». Вставка новых объектов происходит как правило на порядок реже чем запросы по ним. Если идет непрерывный «поток вставки», обычно не требуется немедленно получать ИД. Ну а если уж требуется быстро и много «вставлять» и отдавать ИД, можно одним запросом «забронировать» сотню ИД и раздавать ее на клиенте.
Вот и википедия говорит, что «Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов» (http://ru.wikipedia.org/wiki/GUID)