Странно слышать про «первый нейроинтерфейс» и не упомянуть Emotiv первая девелоперская версия которого у меня лежит с 2010 года (она тогда была еще страшная на вид и реально прототип напоминала, текущие законченные изделия куда приятнее и футуристичнее выглядят)
Часто используемый вариант для картинок где в пути важен именно primary key (хотя как по мне если есть путь и обработка дубликатов с автопереименованием уже встроена в storage по дефолту для File/Image field) можно спокойно использовать UUID field в качестве primary key:
import uuid
from django.db import models
def directory_path(instance, filename):
return 'images/{0}/{1}'.format(instance.id, filename)
class MyUUIDModel(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
upload = models.FileField(upload_to=directory_path)
FileField и ImageField в базе как раз и хранят путь к файлу в рамках стораджа который указан для поля модели (а стораджами могут быть кто угодно от файлов до aws s3)
Что люди только не делают лишь бы документацию не читать :) Django ImageField (Точнее FileField от которого он наследуется) и в версии 1.8, и в версии 3.0 позволяет использовать функцию для определения пути.
upload_to may also be a callable, such as a function. This will be called to obtain the upload path, including the filename. This callable must accept two arguments and return a Unix-style path (with forward slashes) to be passed along to the storage system.
def user_directory_path(instance, filename):
# file will be uploaded to MEDIA_ROOT/user_<id>/<filename>
return 'user_{0}/{1}'.format(instance.user.id, filename)
class MyModel(models.Model):
upload = models.FileField(upload_to=user_directory_path)
если монгу можно использовать для решения различных задач (пускай даже иногда в компромиссном варианте)
Иногда нужно делать одну задачу хорошо, а не несколько — посредственно
elasticsearch в очень многих ситуациях избыточен
я собственно с этим не спорю.
Обращаю внимание, что я не говорю, что elasticsearch лучше mongo, просто уточнил, что если в проекте используется только mysql, то добавление elasticsearch ничем не отличается от добавления mongo
Задача поиска товара по группе фильтров — класическая задача для search engine а не database engine. Советую посмотреть в сторону elasticsearch: www.elasticsearch.org/
В результате нам удалось создать структуру приложения, где все компоненты хорошо связаны, при этом мы добились четкого разделения классов, где каждый класс выполняет свою задачу.
Почитайте пожалуйста значения, смысл и разницу между Cohesion и Coupling.
Также посмотрите реализацию многих компонент (для примера Symfony HTTP kernel, Symfony Routing) и проанализируйте, почему они реализованы именно так, а не иначе.
Ну и также я думаю этот материал будет полезен для чтения. Желательно читать полностью, особенно про namespace
P.S. В описанном в статье решении сами namespace не имеют абсолютно никакого значения. То же самое можно было реализовать и на более старой версии PHP без их поддержки.
А какие устройства используются? Ищу себе подобные и из более-менее адекватных попались только denkovi
Один из примеров что доводилось использовать — www.pimusicbox.com
В elasticsearch искать можно по многим критериям. Подробнее можно почитать здесь www.elasticsearch.org/guide/en/elasticsearch/reference/current/search.html (общая информация о поиске и его типах) и здесь www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-queries.html (собственно часть возможностей поиска)
Также думаю будет полезно ознакомиться с этими статьями на хабре:
habrahabr.ru/company/mailru/blog/213849/
habrahabr.ru/post/122531/
я собственно с этим не спорю.
Обращаю внимание, что я не говорю, что elasticsearch лучше mongo, просто уточнил, что если в проекте используется только mysql, то добавление elasticsearch ничем не отличается от добавления mongo
Это если в проекте уже используется Mongo. Если нет — добавить что mongo, что elasticsearch одинаково
www.elasticsearch.org/
Вот в частности решение одного из описанных кейсов для магазина: www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-facets.html
Интеграция elasticsearch в Symfony + Doctrine — github.com/FriendsOfSymfony/FOSElasticaBundle
plugins.jetbrains.com/plugin/7320
plugins.jetbrains.com/plugin/7219?pr=phpStorm
По ссылкам есть описание возможностей и гифки с демо
Да ничем особо не отличается от предложенных решений.
А вот если использовать и Doctrine ORM, тогда есть возможность использовать магию
P.S. Если кто не знает — Doctrine — это далеко не только ORM, ORM это только один из проектов
PHP: The Right Way
Почитайте пожалуйста значения, смысл и разницу между Cohesion и Coupling.
Также посмотрите реализацию многих компонент (для примера Symfony HTTP kernel, Symfony Routing) и проанализируйте, почему они реализованы именно так, а не иначе.
Ну и также я думаю этот материал будет полезен для чтения. Желательно читать полностью, особенно про namespace
P.S. В описанном в статье решении сами namespace не имеют абсолютно никакого значения. То же самое можно было реализовать и на более старой версии PHP без их поддержки.