TS
самое простое
есть допустим свойство name
есть допустим свойство name
Допустим
Size: a a a
2019 November 26
VH
есть ли на него какие-то ограничения?
TS
давай так, когда ты писал систему на 1кк файлов, zfs уже было?
Да, но я не использовал и делао систему подпапок и разбиение на сервера
TS
есть ли на него какие-то ограничения?
Да
VH
Если брать реляционку - то там либо nvarcharmmax, либо задаешь врунчую
У всех телеграм падает? переодично
У всех телеграм падает? переодично
TS
(node:4273) UnhandledPromiseRejectionWarning: URIError: URI malformed
at decodeURI (<anonymous>)
at Server.<anonymous> (/home/lenin/Projects/SQLInjection/JavaScript/simple.js:13:15)
at Server.emit (events.js:210:5)
at parserOnIncoming (_http_server.js:745:12)
at HTTPParser.parserOnHeadersComplete (_http_common.js:115:17)
(node:4273) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:4273) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.TS
VH
Все упало?
у меня 500 летела просто алертом
OG
Насчет статей я бы сказал что база таки будет полезна. Все равно практически любая "статья" это заголовок, категория, тэги, картинки, короткий текст, инфо об авторе и т.д. и т.п.
А это уже удобнее хранить в базе
А это уже удобнее хранить в базе
TS
Насчет статей я бы сказал что база таки будет полезна. Все равно практически любая "статья" это заголовок, категория, тэги, картинки, короткий текст, инфо об авторе и т.д. и т.п.
А это уже удобнее хранить в базе
А это уже удобнее хранить в базе
Тут невозможно ничего сказать по части задачи, пока неизвестно их кол-во (приблизительно, планируемый порядок цифр, тысячи или сотни миллионов), пока неизвестна их структуру, метаданные, которые нужны для кажой, неизвестно, как их обрабатывать будут, неизвестно, какие запросы кроме полнотекстового поиска будут исполняться, неизвестно, как они классифицируются и группируются, неизвестно приблизительное кол-во запросов, необходимость масштабирования, частота обновлений, ничего. В каком-то млучае лучше делать все в базе, в каком-то только в фс, в третьем - часть в базе, часть в фс, когда-то все в пямяти нужно хранить, или вообще размазать на 2 базы данных. Принимать архитектурные решения в вакууме нельзя.
OG
Вообще я согласен, однако в случае когда задача поставлена неточно и я подозреваю, что топикстартер и сам не до конца понимает масштаб и потербности, я обычно предлагаю самые универсальные решения. В данном случае, имхо, это реляционная бд.
Достаточно гибко чтобы выдержать большинство наиболее распространенных запросов на изменение/расширение функционала, достаточно быстро чтобы (в среднем случае по палате) не создавать проблем
Достаточно гибко чтобы выдержать большинство наиболее распространенных запросов на изменение/расширение функционала, достаточно быстро чтобы (в среднем случае по палате) не создавать проблем
VH
Вообще я согласен, однако в случае когда задача поставлена неточно и я подозреваю, что топикстартер и сам не до конца понимает масштаб и потербности, я обычно предлагаю самые универсальные решения. В данном случае, имхо, это реляционная бд.
Достаточно гибко чтобы выдержать большинство наиболее распространенных запросов на изменение/расширение функционала, достаточно быстро чтобы (в среднем случае по палате) не создавать проблем
Достаточно гибко чтобы выдержать большинство наиболее распространенных запросов на изменение/расширение функционала, достаточно быстро чтобы (в среднем случае по палате) не создавать проблем
я все понимаю, нету никаких проблем. мой основной стак - .Net. Ноду и монго решил просто попробывать, так как нету сдесь опыта - и есть куча вопросов
VH
Статьи - это просто текст обычный со вставками хтмл тегов
OG
Хорошо, а как вы собираетесь их выводить?
Статьи не существуют в вакууме. Обычно они разбиты на категории, выводятся с какими-то краткими описаниями, картинками и т.д.
Статьи не существуют в вакууме. Обычно они разбиты на категории, выводятся с какими-то краткими описаниями, картинками и т.д.
TS
Возможно там будет пейджинг, сортировка, фильтры, связи с другими сущностями, джоины, какие типовые запросы к множеству статей будут идти?
TS
Только обращение по Id или по имени или по контенту только?
OG
Если задача абстрактна: получить статью по айди, то, конечно же, самый беспроигрышный вариант с файлами.
Если появляются метаданные вроде тех, о которых я говорил, ситуация уже меняется
Если появляются метаданные вроде тех, о которых я говорил, ситуация уже меняется
AS
Если задача абстрактна: получить статью по айди, то, конечно же, самый беспроигрышный вариант с файлами.
Если появляются метаданные вроде тех, о которых я говорил, ситуация уже меняется
Если появляются метаданные вроде тех, о которых я говорил, ситуация уже меняется
а как под абстратную задачу делать SQL базу данных?
A
Абстрактной задаче - абстрактный SQL в виде текстового файла abstract.sql куда тупо все сохранятеся через запятую.
OG
а как под абстратную задачу делать SQL базу данных?
Абстрактно )))
Если не знаешь чего ждать, добавляешь самое стандартное типа заголовка, короткого текста, даты создания, ну а остальное уже по мере
Если не знаешь чего ждать, добавляешь самое стандартное типа заголовка, короткого текста, даты создания, ну а остальное уже по мере