Нужно иметь 2 таблицы с 1 полем айди (общим)

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

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

То есть иметь FK на таблицу с айдишниками и иметь внутренние PK айдишники для сущности каждого типа?

Да

Спасибо

Сэкономил кучу времени)

Вообще, можно загуглить реализацию наследования, там есть и другие варианты. У тебя по сути две сущности должны наследоваться от одной.

Ммм, да, тоже хорошая идея

Ммм, да, тоже хорошая идея

Table per Type

вот это наследование сделай

Table per Type

Щас почитаю

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

или адаптеры идут больше для работы с удаленным сервером?

Щас почитаю

https://www.codeproject.com/Articles/796521/Inheritance-in-Entity-Framework-Table-Per-Type http://metanit.com/sharp/entityframework/7.2.php

там в принципе изи

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

В чём профит локальной бд?

той самой что localdb

https://www.codeproject.com/Articles/796521/Inheritance-in-Entity-Framework-Table-Per-Type http://metanit.com/sharp/entityframework/7.2.php

Ага, уже нагуглил, сяп

удобство использования)

Очень сомнительное

ОЧЕНЬ

той самой что localdb

ну а как лучше хранить данные?

Ставь мсскл

ему это оверкилл

с мсскл менеджмент студию

ему там 2 таблицы и 2 строчки в каждой

ему это оверкилл

эмм...

мне кажется в 100 раз легче чем локалдбб

заодно практика норм

это как из пушки по воробьям :)

у меня в 2015 студии локалдб в дизайнере так лагала что я с ума сходил

а разворачивать на каждом клиенте тоже мсскл

это как из пушки по воробьям :)

Хз, практика хорошая

К локалдб можно менеджмент студией так же подключатся

а разворачивать на каждом клиенте тоже мсскл

Справедливо, но если для себя то как раз норм

пофиг же

К локалдб можно менеджмент студией так же подключатся

лол, не знал

у визуал студии есть сервер эксплорер

типа менеджмент студии встроенной небольшой

локалдб - это обычный "портабл" скуэл, если упрощенно

у визуал студии есть сервер эксплорер

Да, вот оно оч лагало на локалдб

я не знаю почему

не исключено что руки крюки

у меня не лагало

так что по адаптерам?)

/start@bestuserbot

/stat@combot

combot.org/chat/-1001066857984

так что по адаптерам?)

используй ef

используй ef

даже не видел такого

используй ef

++++++++

а понял

лан спасибо

https://www.exler.ru/bannizm/images/13-10-2005/11.jpg

EF имеет смысл использовать только тогда, когда нужны tracking changes. В случае простого маппинга сущностей на таблицы - dapper или Linq2Db для более сложных сценариев

И да, я использовал EF в продакшне.

А какие еще ORM кроме EF пользуются популярностью?

А какие еще ORM кроме EF пользуются популярностью?

Даппер, адо

Говорят ещё Чейн крут

+ нгибер на легаси больше, хотя сам он неплох

Вообще ящитаю что топ - гибрид из Даппера + ЕФ

Даппер на узких местах юзается для производительности

Я не понимаю как жить то теперь в кор если нет пакаж.жсон

из 2017 улетели обратно в 2013

Я не понимаю как жить то теперь в кор если нет пакаж.жсон

шта?

все там есть

ты мож про жсон проекта?

ERROR: S client not available

Который депенденси устанавливает

Пингвин с лого эппл в сисярп чяти

project.json

оч подозрительно

Во

.net core жеж

.net core жеж

.нет кор это когда ты девишь на винде а деплоишь на линукс

project.json

.csproj

это да, так изначально было

Ну это ж жесть если сравнивать с project.json =)

только неудобно было редактировать

да хмл вообще пиздец

на работе почти год потерпал из-за него

ммм, пришел домой, думаю щас на коре удобно, прожект жсон

день сурка просто

Не, ребята. Пиздец это json. Когда нужна валидация вводимых параметров

Не, ребята. Пиздец это json. Когда нужна валидация вводимых параметров

Хз, жсон всё и вся юзает

Валидация должна быть на клиенте или на сервере

А не в жсоне

Не, ты не понял

а что?

JSon в msbuild не надо

Как формат передачи данных - он ок

Как файл настроек - не ок

Как файл настроек - не ок

но, эмм... там как-бы он с интелисенсой был

вменяемой

на самом деле, я когда увидел json в msbuild , первый вопрос у меня был - нахрена ?

на самом деле, я когда увидел json в msbuild , первый вопрос у меня был - нахрена ?

Нет громоздкости хмльной

Вот в чём загвоздка

Не, проблема валидации json в общем случае нерешаема