Здравствуйте, Ziaw, Вы писали:

VD>>Я говорю о смысловой перегрузке, т.е. о том как это дело будет воспринимать человек.

Z>Я воспринимаю это так: тип данных PersonId имеет способы преобразования в Person.

Весьма странное восприятие. Тем более что PersonId не является типом данных, да и преобразования тут не происходит.

В общем, на мой взгляд, если ты уж упрашеся в детали построения БД, то нужно быть последовательным и описывать те самые PK/FK.

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

Здравствуйте, Ziaw, Вы писали:

Z>Интересная идея. Я подумаю. Возможно я сделаю просто сокращенный синтаксис. Например так
Z>

Z>create Test
Z>{
Z>    id; // краткая запись для Id : Guid() = Sql.Newid;
Z>    Text : string;
Z>}
Z>

Z>или так
Z>

Z>create Test
Z>{
Z>    noid; // если не указать это, то ключ будет сгенерирован
Z>    Text : string;
Z>}
Z>

Для меня был было лучше если бы вообще не пришлось возиться с этим ID.
В 90% случаев (если не в 99%) ключевые поля, PK, FK и даже индексы строятся по одному прототипу — с введением суррогатного первичного ключа.

Только 1-10% таблиц получают составные первичные ключи или первичные ключи основанные на вводимых пользователями значениях. Вот для них я готов вводить информацию о PK.

А для FK в 100% случаев можно сгенерировать все автоматом. Ведь связи иделаются именно между таблицами. Если мы знаем все PK и тип связи, то без труда можем сгенерировать как и FK-пооля, и сами FK, и всю остальную обвязку. За одно можно (нужно!) генерировать и все аннотации для БЛТулкита.

Z>Ты путаешь описание модели и код миграций.

Скажем та. Мне вообще не очень нравится модель миграций и временами я сваливаюсь на мышление в терминах модельного проектирования.

Z>В коде миграций создают только внешние ключи.

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

Так почему не задавать те же ассоциации? Что этому препятствует?

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

Z>В описании модели уже можно создавать ассоциации, это будут отдельные макры. К миграциям отношения не имеющие. А в миграциях DSL должен прозрачно ложиться в DDL.

Ты говорил о DRY. Но то что ты сейчас говоришь — это то самое повторение себя! Мы один раз описываем связи (их создание, удаление или модификацию) в сктипте, а потом тоже самое делаем в модели.

Точнее даже еще хуже! Мы сначала описываем миграции которые в итоге порождают новые версии моделей, а потом мы еще раз описываем модели! Это явное нарушение принципа DRY.

Z>дроп колонки, что может быть проще?

А так оно и будет. Просто колонка ассоциативная. В случае связи многое-ко-мноким придется сделать удаление двух колонок.

Смотри:

    drop Person.Addresses

и мне не надо думать ни о каких деталях (названиях полей отвечающих за эту связь).

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

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

Z>Я понимаю твою обеспокоенность тем, что ассоциации описывающиеся в модели слегка дублируют код миграций, но это только на первый взгляд.

Почему же это "только на первый взгляд"? Это так на любой взгляд.

Z>В рельсах сделано именно так.

Это не разу не аргумент.

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

Z>Ты настойчиво пытаешься увидеть модель в миграциях, миграции это не модель.

Это потому что миграции меняют модель.

Z>Это инструмент эволюционной разработки, который дает возможность постепенно вносить изменения в схему базы не теряя при этом данных.

Это результат компромисса между декларативностью и надежностью с одной стороны, и гибкостью с другой. Причем компромисса далеко не сторону декларативности и надежности.

Z>Можно плясать от модели, да миграции будут не нужны, но модификации модели будут приводить к неинтуитивным автоматическим действиям с БД.

Про не интуитивный — это домыслы.

Но я сейчас о другом говорю. Раз уж ты выбрал идею императивно но высокоуровнево и абстрактно описывать модификацию БД (она же модель), то нужно постараться как можно лучше выдержать те самые принципы DRY которые ты так хорошо декларировал в своем роадмапе.

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

Ну, и конечно по меньше лишних деталей! Если я могу описать связь одной простой строкой, то не надо ее описывать двумя сложными (да и одной сложной тоже не надо).

Z> Мне эта особенность очень не нравится. Мне нравится указывать явно, все что я хочу сделать со своей базой для приведения ее в новое состояние.

Идея большей настраиваемости хороша сама по себе. Но только если эта идея не конфликтует с идеей большей простоты и более качественны абстракций.

Я не вижу проблем совместить эти идеи в одном флаконе. Ведь нет проблем позволить людям работать как на уровне ассоциаций, так и на уровне полей и ключей. В конце концов ассоциация просто будет приводить к автоматическому формированию этих самых полей и ключей, плюс еще что-то (атрибуты для БДТулкита и т.п.).

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

Здравствуйте, VladD2, Вы писали:

VD>А для FK в 100% случаев можно сгенерировать все автоматом. Ведь связи иделаются именно между таблицами. Если мы знаем все PK и тип связи, то без труда можем сгенерировать как и FK-пооля, и сами FK, и всю остальную обвязку.

А что по твоему делает запись:

  PersonId :> Person;

Она как раз генерит поле PersonId такого же типа как и PK в Person, заодно генерирует FK.

VD>За одно можно (нужно!) генерировать и все аннотации для БЛТулкита.

Брр... Аннтоации тулкиту генерируются во время компиляции модели. Миграции выполняются совершенно в другое время. Могут выполняться тыщу раз на разных базах, откатываться назад и т.п. Не должны они лезть в код модели.

Z>>В описании модели уже можно создавать ассоциации, это будут отдельные макры. К миграциям отношения не имеющие. А в миграциях DSL должен прозрачно ложиться в DDL.

VD>Ты говорил о DRY. Но то что ты сейчас говоришь — это то самое повторение себя! Мы один раз описываем связи (их создание, удаление или модификацию) в сктипте, а потом тоже самое делаем в модели.

VD>Точнее даже еще хуже! Мы сначала описываем миграции которые в итоге порождают новые версии моделей, а потом мы еще раз описываем модели! Это явное нарушение принципа DRY.

Нет, в миграциях мы указываем связи между таблицами, а в модели необходимые ассоциации между объектами. Они могут быть сильно разными.

VD>Самое противное при этом то, что прикладной программист будет вынужден держать в голове множество мелких деталей и мыслить на менее абстрактном уровне.

Да. Будет. Я не собираюсь скрывать эти детали. В первую очередь я делаю фреймворк для себя.

Z>>Я понимаю твою обеспокоенность тем, что ассоциации описывающиеся в модели слегка дублируют код миграций, но это только на первый взгляд.

VD>Почему же это "только на первый взгляд"? Это так на любой взгляд.

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

VD>Я тебе сразу сказал, что миграции в рельсах сделаны плохо. Задачу решают, но совершенно не декларативно и не защищают от дублирования и ошибок.

Я понял только то, что тебе они не нравятся. Я считаю наоборот, для решения своей задачи они очень декларативны и защищают от множества ошибок деплоя.

VD>Это потому что миграции меняют модель.

Именно. Меняют модель в базе. Но не в коде.

Z>>Можно плясать от модели, да миграции будут не нужны, но модификации модели будут приводить к неинтуитивным автоматическим действиям с БД.

VD>Про не интуитивный — это домыслы.

Так развей их. Расскажи принципы работы и докажи интуитивность. Вот был у меня класс

class Test
{
  mutable public F : string;
}

Я его исправил:

class Test
{
  mutable public F1 : string;
  mutable public F2 : string;
}

Что с будет делать твой инструмент с таблицой Test в которой есть записи?

VD>Ну, и конечно по меньше лишних деталей! Если я могу описать связь одной простой строкой, то не надо ее описывать двумя сложными (да и одной сложной тоже не надо).

Именно, только знания об ассоциациях все равно придется дублировать в модели, либо заводить еще одно хранилище для них.

VD>Я не вижу проблем совместить эти идеи в одном флаконе. Ведь нет проблем позволить людям работать как на уровне ассоциаций, так и на уровне полей и ключей. В конце концов ассоциация просто будет приводить к автоматическому формированию этих самых полей и ключей, плюс еще что-то (атрибуты для БДТулкита и т.п.).

Атрибуты куда вставлять при прогоне миграций?

Здравствуйте, VladD2, Вы писали:

Z>>В гибернейте прокатила бы. Там можно создать lazy свойство Airplane и доступ к его айдишнику не заставит гибер лезть в базу, а к полям заставит. Тру абстракция. Когда дойдут руки до поддержки гибернейта ты сможешь это использовать. Если мы так сделаем в тулките — он просто не загрузит Airplane, это сделает работу с ассоциациями чертовски неудобной. И в любом случае никакого отношения к миграциям эти принципы не имеют.

VD>У тебя каша в рассуждениях.

Никакой.

VD>Причем тут lazy?

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

VD>То что ты описываешь Ассоциацию или даже свойство не значит, что через это свойство можно будет foreach-ем перебрать эти зависимые объекты, и что они автоматом закэшируются или будут подниматься лениво.

VD>Ассоциацию позволяют описать те же сущности (ключи, констрэйны и даже поля) в более сжатой форме.
VD>Кроме того они позволяют в дальнейшем использовать в запросах более лаконичный стинтаксис обращения к свойствам вместо использования соеденений (join-ов).

Вот ты сам при работе с тулкитом оставляешь в объектах FK поля или указываешь их через ассоциации? Во всех примерх linq и тулкита эти поля есть. Чтобы создать новый объект мне не нужно доствать из базы Airplane, мне достаточно знать его код. А у тебя вот какая-то каша получается, если убрать FK поля.

VD>Вот что об ассоциациях пишет сам IT:
хъ

Извини, но читать еще раз то что я уже когда то читал я не буду. Есть более емкая мысль — излагай.

VD>Так что БЛТулкит поддерижвает все что нужно. Просто, кончено же, он поддерживает все это дело на более низком уровне.

VD>Делая аналог Рельс для Немерла было бы логично предоставить более высокуровневый вариант описания (на ряду с низкоуровневым) который позволил уменшить объем не нужной писанины и получить дополнительный уровень абстракции.

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

VD>И из этого следут, что нужно оябзательно описывать ее на самом низком уровне выставляя на показ все (даже не нужные) детали?

Какие детали конкретно не нужны?

VD>А вот это большой вопрос. Кракто у тебя не очень получается. Ты хочешь заставить людей описывать тучи деталей. Лично мне совершенно по барабану каке там в БД создадутся констрэйны, ключи и т.п. Мне нужно вырзить отношение между сущностями и чтобы потом я мог сделать выборку по этим отношениями или вставить данные учитывая имеющиеся ассоциации.

Отношения 1-1 и 1-* описываются ровно одной простой строкой. Насчет *-* я еще подумаю.

VD>Рельсы и Грелься как раз предлагают такой путь. По умолчанию мы описываем все максимально просто и высокоуровнево, но если захотим, то можем спуститься на уровень ниже и описать конеретные детали.

VD>Так и надо поступать.

Да я вроде полностью скопировал идеологию рельсовых миграций, чего ты еще от меня хочешь?

VD>Проблемы Рельсов возникают отнюдь не во время описания миграций или эктив-рекордов. Они возникают когда с объектами начинают работать как с ОО-сущностями, а не как с кортежами и отношениями.

От этого я и пытаюсь избавиться. А ты зачем-то киваешь на статьи про дырявые абстракции и максимальное сокрытие деталей БД.

VD>Ты их пока что успешно игнорируешь.

Да ладно, все что более менее вменяемо я беру в расчет.

VD>Я тебе выдаю свои мысли. Делюсь совими знаниями и опытом. Ты же волен прислушаться или игнорировать.

VD>Где-то ты споришь потому что просто не понимаешь меня (видимо мешает терминалогия). Но где-то ты откровенно не прав. Я тут поделать ничего не могу. Проект твой и все в твоих руках. Держать тебя за руку я не мугу (не хочу). Просто бобидно когда делаютс откровенно не верные дизайнерские решения. Вот я и высказываю свое мнение, чтобы попытаться предупредить такие просчеты. Услышишь — хорош. Нет — ничего не поделаешь.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Ziaw, Вы писали:

VD>>>Я говорю о смысловой перегрузке, т.е. о том как это дело будет воспринимать человек.

Z>>Я воспринимаю это так: тип данных PersonId имеет способы преобразования в Person.

VD>Весьма странное восприятие. Тем более что PersonId не является типом данных, да и преобразования тут не происходит.

Тип данных [колонки] PersonId имеет способы преобразования в Person. Т.е. я могу произвести взаимно однозначное соответствие между значением PersionId и объектом типа Persion.

Здравствуйте, Ziaw, Вы писали:

Z>Тип данных [колонки] PersonId имеет способы преобразования в Person. Т.е. я могу произвести взаимно однозначное соответствие между значением PersionId и объектом типа Persion.

Для меня как дизайнера модели данных (БД) это все лишнее. Я бы желал просто задать ассоциацию между сущностями и пользоваться результатами.