Efektywne przechowywanie danych

Witam.
Czy poniższy sposób przechowania danych o kolekcji książek będzie optymalny?

public class Magazyn
{
        public List<BOOK> Baza = new List<BOOK>();
        
        public struct BOOK
        {
            public int id;
            public string nazwa;
            public string autor;
            //inne pola
        }
}

Interesują mnie takie operacje jak: dodawanie, usuwanie, modyfikowanie, sortowanie elementów.
Czy można inaczej, bardziej wydajniej przechować i operować na takich danych.
Czy wybór listy struktur jest dobrym rozwiązaniem?

Dane będą zapisywane w bazie SQLite.

Nie jest dobrym rozwiazaniem. Lepiej byloby zastosowac mapę hashującą, w której kluczem byłoby ID, a wartością BOOK. Wtedy wyszukiwanie danych po ID masz prawie w czasie stałym a nie liniowym. Usuwanie i dodawanie tak samo szybkie, jak w liscie.

Wg mnie do takich celów został stworzony DataTable ;)

[losowa nazwa] napisał(a)

Nie jest dobrym rozwiazaniem. Lepiej byloby zastosowac mapę hashującą, w której kluczem byłoby ID, a wartością BOOK. Wtedy wyszukiwanie danych po ID masz prawie w czasie stałym a nie liniowym. Usuwanie i dodawanie tak samo szybkie, jak w liscie.

Masz na myśli Dictionary?

Dictionary<int, BOOK> Baza = new Dictionary<int, BOOK>();

Strukturę BOOK mogę użyć, czy też zastąpić ją czymś innym?
W C# stawiam pierwsze kroki.

Strukura BOOK może być w klasie Magazyn, czy wyrzucić ja na zewnątrz?

Masz na myśli Dictionary?
Dictionary<int, BOOK> Baza = new Dictionary<int, BOOK>();

Pytanie niby nie do mnie, ale tak, chodziło o Dictionary.

Strukturę BOOK mogę użyć, czy też zastąpić ją czymś innym?

Strukturę zostaw, zastanów się może nad sensem pola id i ewentualnie go usuń(czy chciałeś używać go tylko w programie czy to jakaś własność twoich książek). Może nic mi do tego jak dla ciebie najładniej wygląda kod, ale ogólnie jest przyjęte (w .NET) nazywać struktury konwencją Pascal (Book zamiast BOOK). Niby nie ma żadnego znaczenia, ale...

Strukura BOOK może być w klasie Magazyn, czy wyrzucić ja na zewnątrz?

To zależy czy chcesz używać jej też poza tą klasą. O ile się orientuję z pierwszego posta, chcesz (zresztą co to za magazyn z którego nic nie można wziąć) więc wyrzuć ją na zewnątrz.

MSM napisał(a)

Strukturę zostaw, zastanów się może nad sensem pola id i ewentualnie go usuń(czy chciałeś używać go tylko w programie czy to jakaś własność twoich książek). Może nic mi do tego jak dla ciebie najładniej wygląda kod, ale ogólnie jest przyjęte (w .NET) nazywać struktury konwencją Pascal (Book zamiast BOOK). Niby nie ma żadnego znaczenia, ale...

Pola Id nie będzie, bo wykorzystam klucz z Dictionary.
Struktura będzie miała około 30 pól opisujących właściwości ksiązki, tj:
tytuł, tytuł oryg., ilosc stron, autor, wydanie, tłumacz itd...

A czemu używasz struktury a nie klasy?
Cały magazyn będziesz na raz trzymał i przetwarzał w pamięci?

somekind napisał(a)

A czemu używasz struktury a nie klasy?

Zły nawyk z vb6, gdzie struktura była zupełnie czymś innym niż w c#

somekind napisał(a)

Cały magazyn będziesz na raz trzymał i przetwarzał w pamięci?

Baza będzie zawierać spis książek. Chcę wczytać do pamięci tylko te, które "mam-chcekupić-chcesprzedać"
Rozumiem, że wtedy lepiej użyc klasy?

Jeszcze jedna kwestia dotycząca bazy danych i operacji na niej.
Wydajniej jest mieć jedną tabelę np "Książki" z polem określającym stan "mam-kupię-sprzedam"
czy utworzyć tabele "Mam" "Kupię" "Sprzedam" i trzymać w niej Id z tabeli "Książki"?

Oczywiście, że sposób 2. Na tym polegają relacyjne bazy danych ;)

Choć....

Zależy ile tych książek będziesz miał. Jeśli dużo to wiadomo (patrz wyżej), ale jeśli będziesz miał powiedzmy 20 książek to nie opłaca się bawić w relacje, utrudni Ci to tylko tworzenie zapytań do bazy (choć lenistwo jest złe i będą leniwym nie nauczysz się wiele) to tak po prostu będzie łatwiej.

Oczywiście, że sposób 1. Na tym polegają relacyjne bazy danych.

O ile dobrze rozumiem Twój problem, to Twój system ma się zajmować książkami, bytem-obiektem w nim jest książka. Książka ma swoje atrybuty (autor, cena, itp.) oraz może znajdować się w jakimś stanie (mam, kupię, sprzedam). W tym przypadku stan książki też jest jednym z jej atrybutów. Podobnie też będzie Ci łatwiej wyciągnąć książkę po stanie z jednej tabeli zamiast kombinować z wieloma tabelami.

Ile książek będziesz na raz przetwarzał w pamięci, że jest dla Ciebie ważny dobór struktury danych do ich przechowywania?

I nie widzę żadnego powodu, żebyś miał używać struktur zamiast klas. Struktur używa się tylko w pewnych szczególnych przypadkach, ogólnie rzecz biorąc są nie powinny być modyfikowane po utworzeniu, nie powinny zajmować więcej niż 16 bajtów pamięci, a do tego są typami wartościowymi, więc wszelkie operacje na nich wymagają tworzenia kopii obiektu. Ich użycie tylko skomplikuje Ci pracę.

somekind napisał(a)

Ile książek będziesz na raz przetwarzał w pamięci, że jest dla Ciebie ważny dobór struktury danych do ich przechowywania?

Powiedzmy, że w bazie będą dane kilku tysięcy pozycji. Wczytywał będę tylko te, które mam lub chce kupić, ile tego będzie -
trudno powiedzieć. Podsumowując - wybieram klasę zamiast struktury i jedną tabelę z polem określającym stan zamiast kilku tabel. (łatwiej utworzyć zapytanie)

Rozważam jeszcze użycie DataTable, bo spełnia moje wymagania i chyba najlepiej się sprawdzi.