1 Абстрактная модель всех перечислений:
namespace Schools.Abstract
{
    public class IEnumeration
    {
        public virtual string Name { get; set; }
    }
}

2 Непосредственно перечисление:
namespace Schools.Models.Enumeration
{
    public class BuildingType : IEnumeration
    {
        public override string Name { get; set; }
    }
}

3 (использование перечисления):
    public class Building
    {
       ...
       public BuildingType BuildingType { get; set; } // Тип здания
    }

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

(0) Куда то вы не туда...
Вот оно :
enum Season
{
    Spring,
    Summer,
    Autumn,
    Winter
}

+ (1)

Season x = Season.Summer;

Хотя и не рекомендуется использовать. Оно хуже чем Object. Но под ваши требования ЦЫ()"сделать список доступных значений, а не что угодно" вполне себе.

(1) (2) Хранить перечисление в таблицах SQL - неправильно? Значения непосредственно в коде хранится, как в (1), а в таблицах SQL, использующих перечисление, значение в столбце это просто строка (sting) ?

(3) лучше хранить числа, а перечисление объявить так:

public enum Season
{
    Spring = 1,
    Summer = 2,
    Autumn = 3,
    Winter = 4
}

(4) точно, спасибо!

(3) Стоп. В заголовке темы нигде нет упоминания за SQL.
В КОДЕ. Рекомендуется использовать Object вместо enum. По сути к элементам перечисления можно обращаться по индексу.
В SQL вы точно также не сможете хранить ни enum ни Object. Логично в БД хранить индексы значений типа enum.
Ограничить список значений доступных к записи в таблицу SQL можно при помощи триггеров. Но это уже не относится к C#.

(6) Чем Object лучше?
Про то, что их не записать в таблицу и так знаю, понимаю, что нужно писать что-либо из примитивных типов - строку или индекс.

(7) в данном случае object хуже - enum хранится в стеке, с ним нет затрат на упаковку и gc

(0) Почитай про ORM

(9)+ https://qna.habr.com/q/47

обычно Entity Framwork юзают в C#

(10) Я на Entity Framwork и строю. Не знаю, как организована реляционная база данных в Entity Framwork, делаю в полях идентификаторы строк других таблиц.

(11) Имхо ты слегка ошибся форумом

но "делаю в полях идентификаторы строк других таблиц" чушь
там по ORM модели просто связанные объекты, а в реляции фреймворк сам укладывает
если Enum сделать то просто числовое поле будет в табличке, причем длину поля подберет от длины перечисления

(13) Ок, передам логику библиотеке. Пойду вкуривать документацию.

(14) большинство ORM фреймворков они сами умеют таблицы с нужными полями создавать по объектной модели
хотя и вручную можно но зачем?

некоторые умеют в обратную сторону по таблицам в бд создать шаблоны классов, затем их правишь/допиливаешь

(15) Вот сейчас и попробую накидать классы и посмотреть, что насоздает EF из них в SQL.
Тяжело грызть гранит науки. Я уже позабыл какого это с тех пор как 1с освоил.

https://infostart.ru/1c/articles/402038/

(16) Глянул. EF делает то же самое, что делал и я, только у него имя столбца связанной таблицы "AreaId", а у меня "Area_Id". Значение то же самое - ID совпадает. Ну хоть мыслим с EF одинаково.

(17) Спасибо за ссылку, почитаю, когда свое закончу. Мы же русские так делаем, открываем инструкцию когда уже сломаем)

(15) Собсно, EF и умеет.

(20) когда я работал с EF он только-только появился первой версии
сча вроде как 4-я

(21) Разве не шестая?

(21) EF-Core сейчас уже, он кроссплатформенный (ага, дождались, когда уже не нужно было). Да, все это здорово, но я просто оставлю это здесь:
https://www.prisma.io/

(18) Не понял. Что делает EF?
У тебя в (0) перечисления сделаны через экземпляры класса?

Ну и перечисления в 1С, имхо, сложнее устроены.

Linq2DB более эффективней
https://github.com/linq2db/linq2db
https://linq2db.github.io/index.html
http://rsdn.org/forum/prj.rfd/7762424.flat

(23) а к призме случайно UI нету? с нормальными гридами

(25) Есть, из коробки
https://www.prisma.io/studio

(24) Эффективнее чем EFCore?

(26) Он поменьше, но при этом больше возможностей