Хранилище базы данных vs Хранилище файлов

Question

Мне нужно сделать систему счетов, где счета-фактуры должны храниться в течение 10 лет. Каким будет лучший способ хранения счетов-фактур?

1. SQL базы данных:

Ex: 

• Таблица клиента (код, название, адрес, тел ...)

  -Таблица продукта (PART_NUMBER, описание, цены. ..)

  -Таблица счета (Invoice_No, Client_code, Product, Quantity ...)

Продукты, счета-фактуры будут отслеживаться уникальный номер счета .:

Invoice_No | Client_Code | Product | Quantity 

000000001 | Bob_025445 | Shoes...| 7 

000000001 | Bob_025445 | Shirt......| 17 

000000002 | Susan_22111| Hat.......| 1 

000000001 | Bob_025445 | Boots ...| 1 

2. Сохранить фактуре в файл: класс Serialize в файл:

public class Invoice implements Serializable { 
    private String invoiceNr; 
    private Date invoiceDate; 
    private Client client; 
    private List<products> products; 

    ... 
    } 

Serialize в 00000001.inv , 00000002.inv ... и deserialize для дальнейших консультаций, печати и т. Д. Сохранение файла Я могу сгенерировать XML, но у меня будут те же проблемы, что и в случае с сериализацией. Первой моделью проще создавать отчеты для каждой детали и быстро, но через 10 лет с 10 счетами в день и всего по 10 наименований каждый счет-фактура таблица счетов будет довольно большой ...

Вторая модель кажется, лучше, но, если я хочу, например, создать отчет о «Кто купил обувь», программе придется перебирать каждый файл, ведьма очень медленная.

Итак, пожалуйста, помогите мне с любым предложением или третьей идеей. Ведьма - лучшая практика?

Спасибо!

Answer 1

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

Есть много причин, большинство двигателей баз данных разработаны для масштабируемости, а производительность и надежность, которые вы получаете от них, в большинстве случаев намного лучше, чем писать один в ваших руках, а также абстрагировать многие сложности, файлы сложны, и вы не узнаете об этом до тех пор, пока не попробуете его, это намного проще с SQL.

Обратите внимание, что некоторые базы данных на самом деле основаны на файлах (например, sqlite), поскольку они хранят все в файле и не нуждаются в сервере.

Независимо от того, подходит ли сервер базы данных (например, mysql) или файл на основе sqlite, зависит от вашего приложения, файловая система подходит для данных настольных приложений, а mysql подходит для веб-приложений (или любого приложения, которое сети).

Все эти и многое другое, вы можете сделать некоторые вещи, чтобы улучшить производительность базы данных (например, индексы) и методы, которые вам дают, так сложно реализовать вручную.

В вашем случае я предлагаю вам использовать механизм базы данных, хотя я не могу сказать, являются ли sqlite или mysql или другими, так как это зависит от ваших потребностей.

Один совет оставлен, считается, что неправильной практикой является определение первичных ключей как строк (Invoice_No должно быть целым числом), вы можете управлять его форматом и максимальным размером, чтобы вам не понадобилась строка.

Единственное, что я буду беспокоиться при использовании SQL-базы данных, это язык программирования, который я буду использовать для подключения к нему, у меня нет опыта работы с java здесь, но в C# это просто с LINQ.

Answer 2

Я думаю, что это касается больших данных ... он подходит для большого хранения и быстро генерирует отчеты. Просто убедитесь, что вам не нужно обновлять эти данные, когда они готовы их хранить.

есть большие идеи для реализации IBM концепций Big Data, но есть и другие идеи больших данных от Google и MS ....

Answer 3

Я предлагаю вам имея две таблицы в старомодной реляционной базе данных ментальности , Invoce и InvoiceHstr (разделены на дату счета).

Кроме того, у вас может быть таблица «Заголовок» для сводного отчета.

InvoiceHeader (Держит продукт, numberOFSold ..., FromDate, Todate) и т.д.

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

Для подробного поиска и получения дополнительной информации используйте объединение двух таблиц.

Кроме того, если эти счета принадлежат оператору связи или банку, то вы должны использовать методы BigData. Также вы можете использовать некоторые запросы кэширования BI.