LINUX.ORG.RU

Список сложных объектов или словарь из них же

 , ,


1

1

Это снова я. В предыдущих сериях темах упоминался класс для описания людей. Так вот, если я хочу насоздавать, допустим, пару тысяч его экземпляров с произвольными параметрами — во что удобнее их объединить? Можно в список — и ориентироваться по индексам, можно присвоить каждому уникальный ключ и собрать их в словарь.

С точки зрения объёма кода разница, вроде, невелика. Для внешнего пользователя тем более безразлично, потому что у всех экземпляров разные имена (значения self.name), и если кто-то захочет посмотреть сведения про Ивана Иванова, то будет искать его как раз по имени. Может быть, будет разница в скорости операций с этим самым списком или словарём?

Я обычно всегда выступаю против преумножения сущностей на пустом месте, но в данном случае плюсую sqlite, как самое оптимальное по удобству/простоте/производительности решение
Возможно отпугивает слово «DB» - зря, это не какой-то клиент-сервер, в контексте твоего сценария ты можешь воспринимать его просто как некий pickle для своей структуры данных

zolden ★★★★★
()
Ответ на: комментарий от zolden

воспринимать его просто как некий pickle для своей структуры данных

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

al_exquemelin ★★★
() автор топика
Ответ на: комментарий от al_exquemelin

Мне не очень понятна задача.
Давай назовём sqlite словом 'advanced pickle', чтобы не смущать умы термином DB.
Этот advanced pickle уже включает всю логику для хранения данных и необходимые API для оперирования ими, не привнося никакого оверхеда в инфраструктуру решения.
То есть ты можешь не париться скучными низкоуровневыми деталями, а сразу, вот уже прям сейчас, начать заниматься «бизнес-логикой».

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

zolden ★★★★★
()
Ответ на: комментарий от zolden

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

Имхо, БД — это всё-таки стрельба из пушки по воробьям. Если бы я делал прицел на много пользователей (типа MUD), тогда, может, был бы смысл.

al_exquemelin ★★★
() автор топика
Ответ на: комментарий от al_exquemelin

Имхо, БД — это всё-таки стрельба из пушки по воробьям

Это всё вкусовщина.
В твоём сценарии это реально будет чистой воды аналог pickle.
Ну или как configparser, который INI файлы парсит.

Там ни сервер не нужен, ни пользователи, ни дополнительных конфигов, ни установка чего-то библиотек, так как этот модуль есть искаропки.

В плане практики это вполне востребованный кейс, даже Chrome хранит данные в sqlite

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

zolden ★★★★★
()
Ответ на: комментарий от zolden

даже Chrome хранит данные в sqlite

Дожили, браузер тащит за собой базу данных. Ладно, посмотрю, что там можно выжать.

Что мне точно нужно — так это парсинг какой-нибудь фигни для конфигов объектов, типа JSON или YAML :) Но это уже другой разговор.

al_exquemelin ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.