Сделать поля в модели уникальными через EF

Доброго времени суток. У меня есть модель в EF и через миграцию генерирую соответствующую таблицу. Как силами С# задать полям этой таблицы ограничение unique?

0

JustAnAnimal, блин, EF в первую очередь для работы с СУБД, а не для создания схемы базы. EF много чего создавать при миграциях не умеет, что реально может понадобиться в работе (с тем же EF). Я настоятельно рекомендую схему базы создавать руками, а не баловаться миграциями.

Если по вопросу, то смотрите документацию.

1

Usaga, я умею создавать руками, но сейчас по заданию мне нужен именно EF. За индексы спасибо

0

Usaga, можно найти вариант попроще.

Тема вроде неплохо проиндексировалась, так что добавлю этот вариант, вдруг кому пригодится:

0

Сообщение от JustAnAnimal можно найти вариант попроще.

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

0

Usaga, а что не так с миграциями то? Ты серьезно собираешься каждое(на некоторых проектах очень частое) изменение бд переписывать руками через sql-запросы? Пока я не нашел ничего, чего бы EF не смог сгенерить, просто иногда нужно поискать. Все сейчас пользуются им и это норма. И соответственно, он умеет все больше и больше.

0

Сообщение от JustAnAnimal а что не так с миграциями то?

Я выше написал уже: они далеко не всё могут, что нужно в реальных проектах. В Hello World их хватает, да. Но в реальных - нет.

Сообщение от JustAnAnimal Ты серьезно собираешься каждое(на некоторых проектах очень частое) изменение бд переписывать руками через sql-запросы?

Да. Пока у вас игрушечный проект, то можно и миграциям довериться. А когда начнутся реальные данные, да ещё и сложная схема базы, то руками миграцию выполнить будет надёжнее. Да и тащить в проект EF чтобы он базу мигрировал вместо того, чтобы просто SQL-скрипт в инсталляторе выполнить... Ну вы поняли)

Сообщение от JustAnAnimal Все сейчас пользуются им и это норма.

За всех не говорите. Далеко не все EF'ом пользуются, не то, что его миграциями.

Сообщение от JustAnAnimal я не нашел ничего, чего бы EF не смог сгенерить

Значит у вас такие потребности. Это не хорошо и не плохо, но это не значит, что раз вам хватает, то и всем хватит возможностей миграций.

0

Сообщение от JustAnAnimal Ты серьезно собираешься каждое(на некоторых проектах очень частое) изменение бд переписывать руками через sql-запросы?

По-хорошему, в базе должна быть SP типа _usp_create_database, в который создаются все сущности БД, вся схема полностью.
Плюс SP _usp_fill_database, где все запросы INSERT, DELETE и т.д., которые заливают данные откуда-то (Excel,csv, xmlm другая база и т.д.).
При необходимости изменений в схеме правятся эти хранимки. В ORM только выполняется обновление Модели.

Это правильный подход, поскольку не зависит ни от каких EF и его можно использовать вообще без "Студии".
Представьте ситуацию, когда есть БД и есть работающее приложение с этой БД. Но возникла потребность в проектировании нового приложения, которое связано в добавлении новых сущностей в БД. При этом старые не трогаются.
С Вашим подходом нужно либо импортировать Модель и крыжить ее в новом проекте. Либо создавать по-новой всю целиком. При этом может закосячить старый проект. И я уже не говорю про пресловутую "миграцию". В общем, получается жуткий гемор. Добавьте сюда ситуацию, когда другие приложения для этой базы писаны вообще не в "студии"

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

Добавлено через 4 минуты
Если на "некоторых" проектах возникает необходимость "частого" лазания в базу, - это значит, что разработчик изначально не серьезно подошел к проектированию СУБД, не изучил предметную область, не разобрался с документооборотом, неверно определит состав сущностей и их характеристики.
Т.е. проявил скоропалительность и незрелость.
Это все равно, что строить дом, не имея чертежей, а используя лишь "мысли из головы" или какие-то карандашные наброски.

0

Usaga, возможно, тут спорить не буду. Но EF не мой выбор, а выбор компании с многолетним опытом, в которой я стажируюсь. Там прямо и говорят, юзай миграции, для того они и сделаны. Значит, потенциально проектов, где нужны руки не так уж и много. Ну и да, уметь работать руками было одним из ключевых требований при отборе, но на практике я пока этого не видел. Все идет к упрощению и удешевлению разработки: фронт и бэк строятся на фреймворках, десктоп аналогично, вот и до баз данных прогресс дошел. Это жизнь, нужно привыкать. 90% случаев, где это выгодно, окупят оставшиеся 10.

p.s. "Все" это преувеличение, имелось в виду >50%. Сужу по требованиям в вакансиях, где почти повсюду EF.

Добавлено через 3 минуты
MsGuns, очень часто заказчик меняет требования, отсюда и изменения. Плюс все мои комментарии касаются разработки. Перед релизом можно и переписать базу руками. Это мое лично мнение, но EF получил такую популярность неспроста. Значит, он реально нужен.

0

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

0

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

Я понимаю такой расклад. Но до тех пор, пока компания не начнёт запинаться о эту ORM и её миграции. У нас так же было: взяли EF и радовались как дети. Теперь же планы строим как его в проекте изолировать и выкинуть к чертям. А миграции мы взять не могли. База слишком сложная и большая. Если бы вы видели те скрипты, что у нас для миграций пишутся, вы бы меня поняли.

Сообщение от JustAnAnimal Сужу по требованиям в вакансиях, где почти повсюду EF.

Ну так. Каждый первый учебник по ASP.NET MVC демонстрирует обращение к базе через эту ORM. Оттуда и популярность. Познер однажды сказал:

Если каждый день показывать по телевизору лошадиную задницу, то однажды она станет знаменитой.

Вот это как раз описывает причину популярности этой ORM.

1

MsGuns, ну это вопрос не ко мне, а к лидам или кто всем этим заправляет. Но без EF я никуда не трудоустроюсь отсюда и этот пост и продолжение "подсаживания" на него. В самом деле, не могу же им запушить txt с текстом "Ваш EF - говно, как и ваш многолетний опыт, мне так на киберфоруме сказали" ?

Добавлено через 38 секунд
Usaga, см выше

Добавлено через 4 минуты
Usaga, а вообще, я так думаю, что на большую и сложную базу никто EF ставить и не будет. Просто нужно знать, куда можно его совать, а куда нельзя.

0

Сообщение от JustAnAnimal "Ваш EF - говно, как и ваш многолетний опыт, мне так на киберфоруме сказали" ?

Не надо ничего пушить. К этому сами придут рано или поздно)

Ладно, не вижу смысла спорить о том, что вы не решаете. Сказал использовать - придётся использовать.

Добавлено через 7 секунд

Сообщение от JustAnAnimal "Ваш EF - говно, как и ваш многолетний опыт, мне так на киберфоруме сказали" ?

Не надо ничего пушить. К этому сами придут рано или поздно)

Ладно, не вижу смысла спорить о том, что вы не решаете. Сказал использовать - придётся использовать.

0

Сообщение от JustAnAnimal очень часто заказчик меняет требования, отсюда и изменения.

Не знаю, что у Вас за

Сообщение от JustAnAnimal компания с многолетним опытом

, но, похоже, что в ней работают не очень профессионалы.

Вы в курсе, что перед тем, как браться за любой конкретный проект, пишутся "Исходные требования" совместно с Заказчиком, которые оформляются как договор, вполне себе конкретный юридический документ, который подписывается Заказчиком и Исполнителем ? И если через время Заказчик говорит, что вместо торгового центра нужно построить аэропорт, то составляется новый документ, который опять же подписывается и оплачивается дополнительно.
Ответственность сторон - обязательно условие при реализации любых проектов, не только IT.
Если в Вашей конторе этого не понимают, то это их беда.

Добавлено через 11 минут
Был такой случай. В 90-х.
Делали проект с серьезным госзаказчиком. Все, как нужно, ИТ, ТЗ, документы - дата,подпись,прОтокол
Сдали, подписали Акт, получили сполна деньги. Через время звонок от Главбуха - все замечательно, но пара отчетов не "влазят" в принтер (а тогда были в основном мартичные принтеры), нужно сделать, чтобы печать была вдоль.

Мы не стали спорить, а провели анализ, выяснили, что это сделать можно, но вовсе не просто - нужно было печатать графикой. А это требовало серьезных трудозатрат. Мы нарисовали "Дополнение к ТЗ", оговорили сроки и стоимость.
Отдали директору. Он глянул на цену, охренел и тут же вызвал главбуха. Вместе они приняли решения, что обойдутся тем, что есть. Вопрос был решен.

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

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

0

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

p.s. От рук я не отказываюсь, просто помимо этого нужен EF

0

0

EF, конечно, Вам освоить придется. Раз требуют. И работать по местным лекалам тоже придется. Будете разрабатывать велосипеды с квадратными колесами - лишь бы платили деньги.
Но если Вы хотите расти до настоящего профессионала, то все инструменты будете выбирать оптимально и также оптимально их использовать.

0

Сообщение от JustAnAnimal EF хорош для таких, как я, которых к серьезным проектам не допустят.

Хм. Пожалуй самое веское оправдание существования этой ORM.

0

Сообщение от Usaga Да ладно вам. Взяли новую технологию для себя популярную технологию. Пускай на ней опыт получают. Профессионалами не рождаются)

0

MsGuns, Usaga, раз уж оно надо, мне проще идти программировать с подходом "вау как классно", чем "опять надо мучить это говно". Касательно неучей, по мне, они в основном оседают во фронте или php и редко доростают до чего-то такого, где их решение имело бы вес во всей индустрии. ИМХО, могу быть неправ.

0