Не про значение слова, а про какой каталог

От куда выполнилась команда, из какой директории

Надо почитать чтонибудь про командную строку и понятие "текущий каталог"

Не нашел по теме ответ. Выдает статьи на тему как сменить текущий каталог командой cd

Привет всем.
Подскажите, нужно ли разбивать на разные сущности, если это характеристики смартфонов.
Информация о процессоре, батарее, памяти и т.д. можно сделать как разные сущности?

зависит от того как будет использоваться

Добрый вечер, я снова к вам с приветом 😄
#вопрос Какие ограничения на Key Size накладываются на базы данных, в частности на Embedded и/или Key-Value ?)
Просто наблюдаю такой разброс по ограничениям, доходит до того, что в той же libmdbx (наследнике lmdb) зависит от page size и максимально от 1300 bytes для 4к page до 21780 byte для 64к page. Честно говоря, даже до конца не понимаю зачем такие большие ключи))
Хотелось бы для написания собственной базы данных ограничить размер ключа 250-255 байтами, но не уверен, как это будет смотреться со стороны 😊
Подскажите пожалуйста, что знаете на эту тему 😃

Ну т.е. я понимаю, что можно посмотреть в книжках устройство СУБД и что такое ACID, но как бы при реализации собственной базы данных и какие ограничения выставлять для Page size, Key size и Value size?

Буду парсить с сайта характеристики и записывать в бд. После выдавать через api

Подскажешь как лучше?

это просто перечислены способы получения-выдачи данных, а не особенности их использования

если хотите их использовать как получили (как есть), и выдавать по апи, как есть - то и сохраните как получили

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

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

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

универсальный ответ (ну чисто имхо)
исходя из требований к функционалу пользователя и его удобства формируется фронтенд, для удобства фронтенда формируется апи, для апи формируется бд которая позволяет сделать необходимое
если коротко то: User->Front->API->db

попытка начинать с разработки бд и предусмотреть все возможные случаи чтобы бд подходила ко всему, обычно не очень хорошо заканчиваются (по опыту)

Спасибо за детальное объяснение.

Создам 2 сущности: одну с названиями характеристик, вторую со значениями.