Sumor

Если вы сделаете идентификаторы каждого объекта уникальным в рамках своей БД, то вы можете обойтись одной таблицей связей и в JOIN не нужно будет дополнительно указывать тип связи.
Например: Объекты типа A имеют идентификаторы вида A1, объекты типа B - B1 и тд. Тогда:
Таблица A
A1 Данные 1
A2 Данные 2
A3 Данные 3

Таблица B
B1 Данные 1
B2 Данные 2
B3 Данные 3

Таблица C
C1 Данные 1
C2 Данные 2
C3 Данные 3

LNK Таблица связей
A1 B1
A1 B3
C3 B2
и тд

Запрос на связи A и B (примерно, без синтаксического разбора):
SELECT * FROM A JOIN LNK ON A.id = LNK.id1 JOIN B ON LNK.id2 = B.id

Нужно ещё учесть, что при таком подходе у связей есть направленность: могут быть связи A1-B2 или B2-A1 и нужно иметь это ввиду: либо дублировать при добавлении, либо использовать другие подходы, либо может быть вам направленность связей как раз и нужна.
Для идентификаторов можно использовать GUID - он гарантированно не будет пересекаться между таблицами, но что-бы определить тип объекта по GUID вам нужно прошерстить все таблицы.

По умолчанию, в консоли Windows кодировка 866.
Переключите кодировку перед выводом.

Console.OutputEncoding = System.Text.Encoding.UTF8;

Либо переключите консоль в режим UTF-8 в батнике:
chcp 65001

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

Для одновременной работы с файлом несколькими приложениями его нужно открывать во всех приложениях со специальным указанием: FileShare.ReadWrite

FileStream s2 = new FileStream(name, FileMode.Open, FileAccess.ReadWrite, FileShare.ReadWrite);

В этом случае все приложения смогут одновременно читать и писать в файл. Это накладывает определённые ограничения на приложения - они должны как-то договариваться и понимать куда они могут писать, а куда - нет.
Каждая программа должна писать только изменения в файл, а не переписывать его - иначе другие программы отвалятся.
Это большой геморрой. Так делать не надо.
Если вы всё-таки решитесь, то нужно файл разбить на блоки. Перед записью в блок программа будет его помечать, что-бы другие программы ждали, пока вы закончите с ним работать, после записи - сбрасывать пометку. Если данные удалились - нужна пометка, что блок удалён, так как нельзя сдвигать файл - его могут читать другие программы. Если данные увеличились в размере - ставить отметку удаления и записывать новые данные в конец. И тд, и тп.
Большая часть из этого заложено, например, в формат dbf. Но реализовывать всё это придётся руками.
Кроме того остаётся вопрос с синхронизацией изменений. Если вы в одной программе поменяли список - как об этом узнает программа на другом компьютере. Это может быть слежение за временем изменения файла, или за специальными отметками в файле ... Постоянные проблемы с синхронизацией, постоянное состояние гонки, взаимоблокировки и т.д. В общем, так делать не надо.
Конечно, если каждой запущенной программе отводится только одна строчка и другие её не трогают, то можно попробовать изменять только её.

Если у вас, в основном, чтения и иногда "точечные" изменения, то можно предложить следующий вариант:
при записи: ожидать завершение всех чтений, а затем блокировать файл с FileShare.None, изменить и отпустить.
при чтении: ожидать завершение записи, если она есть, затем открытие файла с FileShare.Read (это не блокирует другие чтения), быстрое чтение и закрытие файла.
Под ожиданием я понимаю попытку открытия файла с соответствующими параметрами, и в случае исключения повтор через таймаут.

Items используется для "поэлементной" работы, а ItemsSource для подключения коллекций. Нельзя работать с ними одновременно - либо Items, либо ItemsSource.
Поэтому ваш код должен преобразиться примерно в такой:

comboBox2.SelectedIndex = (comboBox2.ItemsSource as System.Data.DataView).IndexOf("Вася");

Но это не будет работать, так как в качестве элементов в ComboBox располагаются элементы из таблицы целиком, а не только имена. Поэтому лучше и удобнее пользоваться свойством SelectedItem, примерно так:

comboBox2.SelectedItem = (comboBox2.ItemsSource as System.Data.DataView).Find("Вася");

А ещё лучше через Binding связать свойство comboBox2.SelectedItem с каким-либо свойством вашей модели и использовать её.

Вне вашего приложения - есть системный индикатор, который можно таскать куда угодно. Хотите сделать такой-же - изучайте хуки.
В вашем приложении вы можете получать текущую раскладку при получении фокуса на ваши окна и выставлять свой индикатор в нужное положение. Для отлова смены раскладки при вашем активном окне - обрабатывайте получение события WM_INPUTLANGCHANGE.

При программировании на C# программирование C++ не нужно. Но часть примеров, особенно если сталкиваешься с чистым WinApi, или с COM (DCOM), или работой с необычными устройствами, написана на C++. Поэтому есть необходимость уметь читать и понимать примеры на C++. А иногда на VB или даже на Delphi.

Простой способ: Для формы разрешите AllowDrop и ловите событие DragDrop. В её параметрах будет описание того, что на вас кидают.

Сложный способ: для затравки прочитайте вот это https://habrahabr.ru/post/179131/.
Там описана реализация на Delphi, но последовательность действий такая же.
Нужно описать все функции, которые используются через DllImport. Вызвать DragAcceptFiles.
Переопределить Wndproc для формы protected override void WndProc(ref Message m), и там обрабатывать событие WM_DROPFILES и через DragQueryFile получить переданный список.

Мне кажется вопрос оптимизации подключения для приложения с одним полем и кнопкой добавить не самый актуальный, но:
Время создания и закрытия соединения с базой данных определяется вашими условиями. Если соединение с базой данных жизненно необходимо программе, и она сразу же грузит из неё данные и продолжает взаимодействовать всё время своего запуска, то в этом случае соединение создают и хранят до завершения программы.
Для некоторых программ, которые точечно взаимодействуют с базой данных, а также если между взаимодействиями возможно отключение БД или доступа к ней по сети, соединения создаются в момент обращения к БД и после работы соединение закрывают. Это как раз очень похоже на ваш случай. При этом можно учитывать, что в действительности физические соединения к базе данных не всегда сразу закрываются при закрытии DbConnection, а придерживаются на случай, если тут же понадобится его открыть.
С другой стороны, возможно сам факт ошибки соединения с БД уже сообщит пользователю о проблемах и ему не придётся узнавать это после заполнения многостраничной формы ввода. В этом случае желательно проверить соединение до ввода пользователя.

using System;

class Program
{
    [STAThread]
    static void Main(string[] args)
    {
        Console.WriteLine("Starting WpfApplication1.exe...");

        var domain = AppDomain.CreateDomain("WpfApplication1Domain");
        try
        {
            domain.ExecuteAssembly("WpfApplication1.exe");
        }
        catch(Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }
        finally
        {
            AppDomain.Unload(domain);
        }

        Console.WriteLine("WpfApplication1.exe exited, exiting now.");
    }
}