Добрый день!

я натолкнулся на одну мысль, и хотел бы спросить людей, возможно, сталкивающихся с подобным вопросом. А именно, вопрос касается хранения данных обычном текстовом файле.
Предположим, нужно сделать БД для некоего бакалейного отдела. Здесь товары которые не нужно делить на какие-то особые свойства, а достаточно хранить обобщающие записи: Сахар-песок ; Сахар рафинад ; Гречневая крупа ; Гречневая крупа II сорт ; и т.д.

не заводить же для этого таблицу под каждую категорию. И в итоге, я наткнулся на один совет на стаковерфлоу:
SoftaТо, что Вы описали, это самое обычное решение данной задачи с точки зрения реляционных баз данных.
Но оно, на мой взгляд, избыточно.
Я Вам больше скажу - для этого вообще база данных не нужна. Недавно сталкивались с сходной проблемой. Думали-думали какая БД, какая структура.
А потом прекратили думать и посчитали: несколько тысяч товаров, описание свойств каждого занимает сколько-то там (уже не помню) байт в среднем. И в целом все наши описания свойств (аналог вашей таблицы prod_attributes) товаров укладываются в менее чем в 200 килобайт.

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

Реализовали такую систему: при загрузке веб-приложения с диска из обычного текстового файла считываются свойства товаров и помещаются в оперативную память в виде удобной для дальнейшей работы структуры.

При обновлении свойств (которое происходит раз в сутки) дергается специальный URI и происходит повторное чтение файла с данными и перезаполнение этой структуры.

Повторяю: база данных для данной задачи вообще не нужна.
BethrezenА как же фильтрация?
Alex78191С помощью LINQ или Stream API.

Так вот вопрос, вы бы как поступили? Делали ли бы, однозначно, всё на реляционках, или рассмотрели бы идею с плоским файлом?

Dimitry Sibiryakov, скажите, а что имеется в виду, когда там говорится про то, что дёргается специальный uri ?
т.е. предположим на сервере лежит текстовый файл, при загрузке сайта он закачивается в ОЗУ на клиенте (или нет)?
в это время, на сервере, происходит обновление данных в основном файле, то клиенту как сообщить, что нужно переписать его клиентский ОЗУ?

что тут именно подрузамевалось, под этим uri ?

или всё же, вся работа с файлом ведётся на бекенде, также как и с бд?

С текстовыми файлами наверное подвяжу. Покубаторил туда-сюда
json не особо-то и советуют, как я понял, мол, если будет куча пользователей, то они будут жрать память на распарсивание даты. В особенности, заметно будет при использовании поиска или фильтра.

Хранить в xml тоже не верный путь. Потому что, xml не имеет механизмов индексации и реляционности данных. Это значит, что с ростом объема xml скорость работы с данными будет падать, причем в прогрессии, а не линейно.

А загонять считку с текста в те же кортежи, чтобы потом искать, а потом не дай боже, понадобиться корзину ещё прикрутить или ещё чего. Опять же, сформировать текстовик с датой тоже откуда-то надо. То, и здесь, в принципе, можно готовую вьюху с индексами в той же бд настроить, чтоб для скорости отбора было.

Поэтому видимо, не выдумывать, а юзать реляционку.

maytonХотя согласен что ТС хитрит
когда он задаёт вопрос и при этом совершенно не определяет платформу.
А смысл хитрить? Рассказываю всё как есть: Сеструхина подруга ипешница, продаёт разный шрот, типа крупы, макарон, консервы... Весь ассортимент шлёт своим тёткам в виде xls (там, фотка, название, описание, цена). Ну понятное дело, мы на очередной пьянке обсудили её трудную и сложную жизнь, и я подписался, что сделаю ей онлайн отображение актуального наличия (просто список как в экселе, но онлайн), чтобы она никому ничего не слала, а те люди могли смотреть у неё на сайте что по чём. Изначально, идея заключалась в том, чтобы привязать её xls к любому фронту. Она сохраняет xls, а он уже отображается на сайте. Виндоус не виндоус, здесь не важно. Важна система хранения подобного типа сведений. Я выберу MSSQL (не потому что с шиком и размахом, а просто у меня есть возможность ей дать место на существующем уже сервере). И потому ещё, что хочу прикрутить поиск FTS. Это даже сугубо лично мне интересно попробовать разобраться. И я надеюсь, что с помощью этого поиска можно будет делать подобные фильтры, как если бы пользователь это делал в экселе. Посему и не хочу организовывать кучу таблиц. Думаю, что достаточно: ID, Caption, Photo, OnStock, Price, Description. И всё. Вот такой сказ. Казалось бы школьная задачка, а я загнался, будто здесь, как минимум, разветвлённая нейросеть с ИИ задумывается. )

Спасибо всем за интересные думки и воспоминания. Клёво было всё это почитать, и DBF и акцесс, и даже перфокарты вспомнили ).

ёёёёёpalladin600,

а потом всю жизнь сопровождать будешь. "Ты ж программист" - (с).
Золотые слова, Людвиг Аристархович - (с) )

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

H5N1palladin600,

обратись к програмситу. минут за 10 тебе поставят и настроят любой движок инет магазина. и будет там и список и поиск и скидки и картинки со всех ракурсов из коробки. за 10 минут.

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

maytonА что вы объяснили? Этож смешно. Топик начался с фразы "База данных в текстовом файле".
Именно. Когда я рассматривал возможность хранения данных в текстовых файлах, то именно так и ставил вопрос. А всё остальное уже, дополненное, пришлось рассказать после того, как кому-то захотелось узнать что к чему и от чего.