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

Подумайте з точки зору попередньо обчислених таблиць пошуку чи чогось іншого. У який момент має сенс використовувати базу даних замість значень жорсткого кодування в моєму додатку? Ці значення не збираються змінювати, і вони добре відокремлюються від розробників технічного обслуговування. 100 значень, 1k, 10k, 100k? Я хочу зберігати близько 40 к значень. Зараз це машино-створене switchтвердження (про яке VS2010 незадоволений).

редагувати:

Якщо комусь цікаво, ось як я підійшов до цього: мої дані зберігаються у двох 100-елементних поплавкових масивах, так це я і зробив. Для генерування даних знадобилося близько 20 секунд, тому я це зробив один раз і серіалізував їх на вбудований ресурс за допомогою BinaryFormatter. Розпаковування даних займає близько 5 мілісекунд при запуску програми, і перевершує реалізацію бази даних, яку я замінював (ці жорстко закодовані значення зберігалися там раніше) майже на 45 000x.

Моя пропозиція - зберігати дані у файлі або таблиці бази даних. Якщо швидкість не є проблемою, то запитуйте файл або базу даних (база даних краще) під час виконання. Якщо пам'ять не є проблемою, але ви хочете деякої швидкості, то завантажте дані в пам'ять при запуску програми. У C # ви можете використовувати та масив, список чи (найкращий варіант) хеш-таблицю та мати метод повернення потрібних даних під час виконання (тобто getDataValue (string keyToValue)).

Я рекомендую вам не використовувати оператор перемикання, оскільки це буде дуже важко підтримувати і призведе до великого сліду exe.

Таблиця хешу, наприклад http://support.microsoft.com/kb/309357

Особисто я готовий зберігати будь-яку кількість даних, жорстко кодованих у програмі, доки немає необхідності підлаштовувати її для одного конкретного розгортання чи виправлення.

Однак зберігання та доступ до даних за допомогою оператора перемикання C # є досить поганою практикою, оскільки в щільно з'єднаних моделях зберігання даних та моделі доступу до даних передбачається лише один метод доступу (за параметром комутатора).

Я вважаю за краще зберігати дані в Hashtable або Dictionary, а також забезпечувати окремі класи для отримання даних та одноразового заповнення пошукових словників.

Нещодавно я виявив досить зручним впроваджувати невеликий DSL для вказівки бізнес-правил ( вільний інтерфейс для SiteMap або питання інтерв'ю з податковим калькулятором, перевірити метод "calc" для визначення правил), а потім надати окремий об'єкт для запиту цих правил. Ця методика добре застосовуватиметься для сценарію вимикача.

Однією з приємних переваг такого розкладу є те, що ви можете реалізувати ряд даних у ваших даних, не торкаючись крапки XXXk рядків, що визначає ці дані.

Заява про перемикання ліній 40k є мало сумнівною. Я припускаю, що вам все одно потрібно виконати операції із запитом, чи не так? Ви спробували інкапсулювати дані? Потім використовуйте LINQ для виконання запитів над колекцією для перевірки продуктивності. Отримайте конкретні часи, запустивши одиничні тести за допомогою таймера, такого як StopWatch . Тоді, якщо ви думаєте, це може просто спрацювати. Подивіться, чи продуктивність прийнятна для користувачів.

У мене була така вимога двічі. Програми були розроблені як окремі, не потрібні налаштування / доступ до бази даних. В обох випадках я використовував XML-файли для зберігання даних. У першому, який знаходився на версії 2.0 Framework, я використовував старий стиль XML для розбору викликів для пошуку даних. Для нової версії 3.5, я використовував LINQ в XML, щоб знайти те, що мені потрібно. В обох випадках доступ до даних був інкапсульований у класах.

Тут головне - переконатися, що ваш загальнодоступний інтерфейс інкапсулює вашу реалізацію, але це не ваше питання, і немає підстав вважати, що ви цього не зробили. Крім того, це лише питання ефективності та скорботи (а відмінності в роботі можуть не варто дбати). Як практичне рішення, для проблеми VS 2010 ви завжди можете розбити заяву справи на ієрархію тверджень справи - верхній рівень може викликати один з 10 інших методів, кожен з яких, наприклад, заява 4000 випадків. Ви можете помістити кожен з 10 у свій власний файл, якщо вам доведеться. Трохи потворно, але ви все одно генеруєте код.

Щодо номера для переключення на БД - це лише коли не використання БД стає проблемою.

Ви можете використовувати щось на зразок SQL Compact. Помістіть дані в таблицю і залиште файл DB у проекті. Таблиці краще підходять для такої кількості даних, ніж оператор перемикання.

Я думаю, що ключове слово тут - навряд чи

Якщо дані ніколи не змінюються - наприклад, заздалегідь обчислені математичні значення, кольорові константи тощо - то впевнені, що поки розмір керований для вас, зберігайте їх у коді. Просто майте на увазі, що якщо продуктивність не викликає труднощів, оператори case / switch будуть дуже повільними порівняно з іншими параметрами.

Якщо дані навряд чи колись змінюються - наприклад, коди телефонів, національні кордони тощо - я, мабуть, намагаюся якось зберігати дані зовні. Особливо, якщо вона почала отримувати більше ніж кілька десятків значень.

Якщо ви зберігаєте великі обсяги даних у вашій програмі, програма може завантажуватися повільніше, і ви можете піддавати код ризику, якщо хтось може зіграти з бінарними файлами або виконуваним файлом.

Крім того, якщо програма редагується багато разів, хто знає, ви можете ввести помилки, помиляючи цифри помилково або в результаті зміни команди.

Можливо, у майбутньому хтось запитає про запуск запитів щодо даних, скажімо, хтось може запитати середнє значення стовпця, і в цьому випадку вам доведеться змінити заявку і додати метод для обчислення кожного запиту, який з’являється ваш користувач. , а потім виконайте всі кроки для просування вашого коду до виробництва. Це справді не добре.

Розмежування даних та коду є хорошою практикою, особливо якщо дані великі.