Бездумный визуальный дизайн табличек, без понятия какой код генерится и зачем это тоже не айс.
Причем функционал любого визуального дизайнера для создания БД будет всегда беднее функционала самой СУБД.
В итоге я пользуюсь обычным листом А4, на который заношу что-то с долгосрочной перспективой, а всё краткосрочное прекрасно запоминаю. После решения задачи этот лист выкидывается, вместо него заводится новый.
Сам ищу удобный для себя еждневник-багтрекер (сервис, десктопное приложение, что-нибудь, неважно), но лучше бумаги и карандаша (именно крандаша, простой серый ТМ), пока не нашел. Можно записать, можно зарисовать, использовать понятные вам символы, обозначение и т.д. Но конечно же тяжело со времененм в этом разбираться, и стол захламляется…
Простой пример периодически спрашивайте себя: то чем я сейчас занимаюсь полезно или приятно?
Разве не может быть компромиссов?
Если человек занимается своим Делом (пусть это и есть работа) и занимается им качественно, то это уже должно доставлять ему удовлетворение и удовольствие.
Тут есть глубокий физический смысл. Когда вы приводите свои мышцы в активность, повышается их тонус, в теле изменяется обмен веществ. Организм понимает, что нужно стать бодрее — и через 10-15 минут разминки вы себя не узнаете.
К этому можно еще добавить зарядку для мозгов.
Например, встав утром (или днем/вечером, у кого как:) ), бывает полезно не сразу погружаться в сложную работу с головой, а начать рабочий день с прочтения нескольких страниц (глав) интересной техничекой книги, статьи, пообщаться на форуме, немного поработать с каким нибудь своим побочным проектом и т.д.
Позволяет легко настроиться на рабочий лад и держать мысли в тонусе.
Обертку — можно (это я кстати и пытался сделать, когда начинал с Mongo), но во первых это придется делать самому (и работать это будет наверняка медленне, а в реляционке уже все в коробке), а во вторых к такой базе не подойдешь ни слева ни справа, только из конкретного приложения, малейший порыв даже самого легкого ветра со стороны — и что то пошло не так.
Но это конечно от задачи зависит.
ПС продолжая аллегорию, можно вспомнить, что Несквик это вроде детский напиток…
Согласен.
Но многие приложения, которые я видел, в любом случае выполняли UPDATE всей строчки, даже если данные во ходной форме изменились только в одном поле, или вообще не изменились. Это конечно не правильно.
16 строчек против 5 плюс абсолютная нечитаемость, и это на элементарном запросе.
К EAV невозможно применить нормальной индексации, при среднем и большом количестве записей «мгновенно» не получится.
В-нулевых, для EAV можно и нужно написать хороший ORM, который будет вас абстрагировать от низкоуровневых объектов.
EAV нужен там, где не достаточно ORM: хранение неопределенного заранее (или постоянно изменяющегося) набора сущностей и аттрибутов.
Если же вы можете заранее построить классы для Ваших сущностей (на основе ORM), то почему бы не использовать обычную реляционку.
Во-первых, для производительности нужно грамотно настроить индексы и саму db а так же можно делать view's (в оракле) или аналоги в других db.
Хотел бы посмотреть как строится индексы для EAV-модели.
Насчет вьюх (и мат вьюх) согласен, т.к. это остается единственным способом хоть как то управлять производительностью и читаемостью запросов. Получется, что вместо таблиц приходится создавать представления.
Причем функционал любого визуального дизайнера для создания БД будет всегда беднее функционала самой СУБД.
Сам ищу удобный для себя еждневник-багтрекер (сервис, десктопное приложение, что-нибудь, неважно), но лучше бумаги и карандаша (именно крандаша, простой серый ТМ), пока не нашел. Можно записать, можно зарисовать, использовать понятные вам символы, обозначение и т.д. Но конечно же тяжело со времененм в этом разбираться, и стол захламляется…
мне сейчас здорово помогает чтение Фаулера по дороге на работу
Разве не может быть компромиссов?
Если человек занимается своим Делом (пусть это и есть работа) и занимается им качественно, то это уже должно доставлять ему удовлетворение и удовольствие.
К своим комментам могу добавить первые две строчки из вашего поста :)
А что вам показалось здесь шуточного? :)
К этому можно еще добавить зарядку для мозгов.
Например, встав утром (или днем/вечером, у кого как:) ), бывает полезно не сразу погружаться в сложную работу с головой, а начать рабочий день с прочтения нескольких страниц (глав) интересной техничекой книги, статьи, пообщаться на форуме, немного поработать с каким нибудь своим побочным проектом и т.д.
Позволяет легко настроиться на рабочий лад и держать мысли в тонусе.
Но это конечно от задачи зависит.
ПС продолжая аллегорию, можно вспомнить, что Несквик это вроде детский напиток…
Но многие приложения, которые я видел, в любом случае выполняли UPDATE всей строчки, даже если данные во ходной форме изменились только в одном поле, или вообще не изменились. Это конечно не правильно.
К EAV невозможно применить нормальной индексации, при среднем и большом количестве записей «мгновенно» не получится.
EAV нужен там, где не достаточно ORM: хранение неопределенного заранее (или постоянно изменяющегося) набора сущностей и аттрибутов.
Если же вы можете заранее построить классы для Ваших сущностей (на основе ORM), то почему бы не использовать обычную реляционку.
Хотел бы посмотреть как строится индексы для EAV-модели.
Насчет вьюх (и мат вьюх) согласен, т.к. это остается единственным способом хоть как то управлять производительностью и читаемостью запросов. Получется, что вместо таблиц приходится создавать представления.
И поэтому, начиная со 2-й версии, от него избавляются:
dimitrigatowski.com/2011/06/19/magento-2-preview/