Улучшение производительности большого DataContext - PullRequest
Новая
       45

Улучшение производительности большого DataContext

0 голосов
/ 21 апреля 2020

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

Тем не менее мои тесты показали, что простое создание экземпляра моего DataContext каждый раз занимает около 90 мс, после того как я сократил количество таблиц, это было мгновенно.

Например, этот код занимает почти 10 секунд: 

For i As Integer = 0 To 100
   Using db As New MyDataContext()
   End Using
Next

Есть ли способ повысить производительность DataContext со многими таблицами или мне следует использовать несколько DataContexts?

1 Ответ

0 голосов
/ 21 апреля 2020

Разумно или нет разделять ваш DataContext на более мелкие отдельные наборы DbSets, зависит от того, связаны ли ваши таблицы и какой тип системы управления базами данных вы используете.

Если вы используете профессиональный СУБД, как и СУБД Microsoft, то для этой СУБД 145 таблиц не так много для обработки. Не будет никаких проблем, если вы храните все свои таблицы в одной базе данных.

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

С другой стороны, для простой СУБД, такой как SQLight, много таблиц и множество одновременных запросов могут оказаться слишком большими для нее.

Если ваши таблицы действительно не имеют никакого отношения друг к другу, рассмотрите возможность их разделения на отдельные базы данных. Например, если у вас есть база данных с клиентами, продуктами, заказами, ценами, счетами и т. Д. c, и другая база данных со школами, студентами, курсами, ClassRooms, преподавателями и т. Д. c. Маловероятно, что какая-либо из таблиц School когда-либо будет связана с таблицами Orders.

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

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

С другой стороны, отдельная база данных даст вам возможность сначала добавить адреса в виде отдельной таблицы в базе данных счетов, а затем в базе данных школ. Вы даже можете решить, чтобы у Счетов была другая адресная система, чем у Школ. Или, может быть, вы хотите, чтобы у вашей системы счетов-фактур была другая таблица адресов, чем в вашей школьной системе.

Итак, следует ли вам разделить:

  • Может ли ваша СУБД обрабатывать большие объемы данных?
  • Связаны ли вы с таблицами? Ожидаете ли вы отношения в будущем?
  • Если есть общие таблицы: проблема в том, чтобы реализовать их дважды?
  • Приведет ли это к дублированию данных, когда вам придется вносить изменения дважды?
  • Хотите ли вы иметь возможность иметь разные таблицы в двух базах данных?

Причина, по которой dbContext находится в локальной памяти, не подходит. DbContext не содержит данных базы данных, он только содержит потенциал для запроса данных.

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

...