Sergey Romanov

/ означает корневую папку хоста, а не текущую. Текущая будет .

Ошибка подключения еще может быть из за метода аутентификации. Но как я вижу вы без пароля запустили. Ни знаю некоторые клиенты без пароли не конектятся нормально.

Все зависит от вашей базы. Если у вас будет 10-100 000 записей, но нет смысла уделять внимание длинне полей. Если у вас 1 000 000 записей в день и больше, то смысл есть. Если у вас база в облаке, то смысл тоже есть.

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

На некоторых облачных базах есть лимиты на размер базы. Да и сами подумайте допустим у вас таблица 100гб. Прочитать такой файл дольше чем файл в 10гб. Хотя если есть индекс и известно от куда нужно читать то будет так же быстро.

Здесь нужно знать ваши мотивы. Медленно работает? Просто хотите сделать правильно? Сколько записей за 6 месяцев попадет в таблицу? Сколько запросов к таблице в час? Какое среднее время обработки запроса?

Ведь возможно все можно решить простой оптимизацией. Возможно созданием реплик. Возможно денормализацией базы, или наоборот.

$sql = "SELECT `id`, `name`, `icon`, `price`, `old_price`, `types` 
FROM `goods` 
WHERE `tags` LIKE '%$query%'  AND `types` =  'old'
ORDER BY id DESC";

Это будет абсолютно не правильно. Сколько цветов ты будешь хранить в базе? 16 000 000 что бы 24 бита глубины цвета получить? Если нужно будет больше?

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

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

Мне кажется это зависит не только от объема базы, но и от нагрузки. Если у вас на сайте много полей с автопоиском, которые при каждой новой букве делают поиск, или другие поиски, то нужно использоать ES. Но не отдельно. Нужно его использовать в паре с базой. Пусть все работает как работает, а поиски через ES. таким образом база разгрузится.

Бывает :)

Кто может подсказать, что использовать, если проект на MySQL, PHP, JS (AJAX)?

То что вы хотите называется two-way-bindings. Это когда на странице без перезагрузки появляются данные которые были добавлены в базу.

Считаю что лучшим решением для это - AngularJS но и если вам понравится то ReactJS. Все будер работать из коробки.

Зпррос

SELECT * FROM my_table WHERE id >= 100 ORDER BY id

и

SELECT * FROM my_table WHERE id >= 100 ORDER BY `date`

Абсолютно идентичны по набору записей которые будут возвращены. Только сортировка записей будет изменина. Но записи и там и там теже.

Нужно понимать что ORDER BY не зависит от WHERE. Вы можете просто сделать

SELECT * FROM my_table WHERE id >= 100

И опять же получить теже записи просто не сортированые.

Я бы посоветовал посмотерть в сторону AWS. Если вы возмете машину в облаке, то ее можно расширять очень сильно. AWS измеряет вычислительные силы в еденицах ECU. 1 ECU это примерно 1 - 1.2 Ghz. Так вот в машне может быть до 32. Это равно примерно 2 х Xeon® E5-1650.

В придчу, вы можете регулировать скрость диска от 100 IO до 20,000 IO. Для примера 100 это работа стандартного HDD 7300 rpm. Но в MySQL не обязательно быстный диск на таблици с данными. Можно просто путь к кешу указать быстрый диск, что бы из кеша быстро читалось.

К тому же вы сможете настроить что то типа распределения нагрзки. Нарпимер с 7 утра до 6 вечера, работает один сервер средний. После 6ти до 12 ночи подключется один большой, а потом переходит на маленький.

Или допустим у вас както особый день намечается. Выход нового проукта и вы ожидаете сотни тысяч людей в этот день. Вы можете увеличить мощьнось серверов только на один день. Заплатить только за этот день. Очень удобно.

В дополнение на AWS есть служба релативных баз данных, которая поддерживает MySQL. Это как бы просто база на обслуживании у AWS. У вас только получается данные соединения для рута. И вы можете что хотите с ней делать. И настраивать мощьности как хотите.

Согласен что возможно AWS дороже чем другие возможные варианты. Но и качество службы беспрецедентное.

И да и нет. Подключить можно но я не уверен что это будет работать. Дропбокс не обеспечить совместной работы.

Для переноса данных нужно в папке /etc создать файл my.cnf где и указать путь к папке.

[mysqld]
datadir=/Users/username/dropbox/xampp/mysql/data
tmpdir=/tmp

Я думаю вопрост стоит не между MySQL и MongoDB а между SQL и No-SQL. Или между MySQL, SQLite, MS SQL, Oracle, ... и MongoDB, ElasticSearch, CouchDB, RavenDB, ...

Я так понимаю вы хотите создать аналог социальных комментариев которые можно инетгрировать в дугие сайты.

Я бы использовал SQL базу так как в данном случае структура данных статичная и вряд ли будет расширятся или менятся. Объемы тоже позволяют сделать быструю систему на SQL базе.

С другой стороны если бы я хотел максимальной производительности при минимальных серверных ресурсах, я бы использовал no-SQL а именно ElasticSearch.

Основное правило такое. Если в условиях WHERE используются колонки таблици которая была JOIN то лучше разбить на вложеные запросы.

В твоем случае делать 2 запроса смысла нет. Можно одним.

Я полагаю вы делаете что то вроде CCK.

Есть 2 подхода как хранить такие архитектуры.

Вертикальный

Это то о чем вы написали. Вы хнарите поля как строки в таблице полей. Для этого вам нужно 2 таблици. Одна это тип. Другая это поля. Где в таблице поля будет ссылка на тип. Таким образом вы всегда можете выбрать список полей этого типа как для построения формы, так и для отображения данных.

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

Хотя я использовал один тип и это достаточно быстро работает до 100 000 записей в разделе. Но если больше то надо конечно свои типы определять.

Естественно каждое поле это РНР класс или на чем вы там пришите. И просто у него есть свойство типа данных. На основе этого свойства и знаешь что дергать.

Горизонтальный

Это когда вы создаете таблицу под каждый тип и добавляете поля в эту таблицу как колонки. Тут можно обойтись одной таблицей.

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

Есть еще свои подводные камни. Я делал CCK для CMS использую вертикальный подход. И пока что не пожалел.