[adek_es]

#cpp #programowanie

Mirki, co będzie najwydajniejszą metodą przechowywania danych wczytywanych z bazy danych w postaci stringów? Czy tablica 2D: std::vector< std::vector< string > > będzie okej, czy są może jakieś sprawniejsze sposoby?

[sylwke3100]

@adek_es: Możesz zamiast wewnątrz vector< string> użyć mapy wtedy będziesz sobie wartość do kolumny przypisywał np zmienna[0]["kolumna"] ale czy to jest wydajniejsze to nie wiem

[adek_es]

@sylwke3100: A czy string map nie da mi tablicy tylko 2xN?

[sylwke3100]

@adek_es: Tego to ci dokładnie nie powiem ale zawołam ekspertów od C++ @kuhar @KrzaQ2

[Kaczus2B]

@adek_es: Zależy jak będziesz później uzywał - nie patrz skąd pochodzą dane, tylko dla jakiego celu je pobierasz!

[michalfranc]

@adek_es: uzyj byle jakiego sposobu zaimplementuj logike i pozniej sprofiluj czy naprawde potrzebujesz optymalizowac te czesc kodu.

[enceladus71]

@adek_es: na pewno powinieneś pomyśleć o tym, jak kontener będzie używany. Zastanów się, czy więcej będzie zapisów, czy odczytów, poważnie zastanówi się nad profilowaniem kodu(co da Ci odpowiedź na pytania z poprzedniego zdania) i pomyśl o zmianie sposobu alokacji w kontenerze. I nie mówię tu o pisaniu swojego własnego alokatora, ale chociażby o zmianie wielkości bloku, który jest alokowany, gdy kontener musi zostać rozszerzony.

[adek_es]

@Kaczus2B: @michalfranc: @enceladus71: Dzięki za odpowiedzi. Co do zapisów/odczytów, to początkowo nie będzie wielu. Dane z bazy danych będą odbierane i prezentowane w postaci grida (projekt w MFC). Być może w miarę rozwoju projektu będzie więcej zastosowań dlatego nie chce po prostu wypisywać gołych danych wprost z bazy, bo byłoby to też trudne nieco.

[l.....l]

@adek_es: Ciężko powiedzieć czy w ogóle jest sens się nad tym zastanawiać, bo większym obciążeniem jest samo ściąganie danych z bazy. Prawdą jest natomiast, że jeśli nie będziesz używał prealokacji pamięci na std::vector, to wektor wektora może być bardzo niewydajny.

[devml]

@adek_es: Jak było napisane wyżej, zależy to od sposóbu dostępu do danych (kolejno, czy po indeksie), ilości zapisów/odczytów i wreszcie ilości danych.
W programach często wystepuje zasada 20/80 - 20% kodu jest odpowiedzialne za 80% czasu pracy programu. Jeżeli te dane nie są krytyczne w odniesieniu do wydajności, lub jest ich niewiele, możesz spokojnie olać kwestię optymalizacji i skupić się na pisaniu kodu, który będzie czytelny i łatwy w utrzymaniu.