MySql, несколько или разные базы данных? 1 поисковая система

Мне нужен совет экспертов, как мне идти с разработкой базы данных?MySql, несколько или разные базы данных? 1 поисковая система

Я создаю платформу веб-сайта электронной коммерции, в которой будут размещены разные веб-сайты электронной коммерции.

1) Чтобы просто понять, что вы можете сказать, родительский веб-сайт является регистратором веб-сайта и будет создавать новые дочерние сайты.

2) Родительский сайт будет иметь интерфейсные шаблоны, которые будут выбраны для дочернего веб-сайта.

3) Каждый дочерний веб-сайт будет полным сайтом электронной коммерции.

4) Будет только один внутренний шаблон (админ-админ), который будет вытаскивать конкретные данные дочерних сайтов, используя данные для входа в систему (имя пользователя и адрес электронной почты).

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

6) Административная сторона каждого дочернего веб-сайта будет иметь возможность резервировать свои данные и загружать их.

Теперь, мне нужно знать, какое решение лучше или я создаю разные базы данных для каждого ребенка? Или использовать ту же базу данных? также будет лучше в производительности.

Просьба дать мне советы по проектированию моей базы данных и таблиц.

Спасибо Миллиону в продвижении ..!

источник

2015-09-10 Sheikh Ayaz Sarwar

Разные databases (или схемы) MySQL могут быть настроены так, чтобы иметь разных пользователей базы данных с их правами и паролями и т. П. Поэтому, если вы намерены предоставить различным веб-мастерам доступ к своему сайту на уровне базы данных, самым простым способом является создание нескольких баз данных.

Для тех операций, которые выполняют поиск по всем базам данных, это недостаток.

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

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

источник

2015-09-10 17:27:18 flaschenpost

Спасибо большое за ваш ответ .. Я сосредоточен на работе над единой базой данных. Хотя это займет время и будет сложно, так как мне придется больше внимания уделять проверкам безопасности. И yess, я буду осторожен, что я не ошибаюсь.! :) Еще раз спасибо. –

Затем вы должны предоставить большинству таблиц столбец client_id, а «backup на уровне строк» должен быть запрограммирован вами через csv/json Download/Upload. Это требует некоторой работы для разделения клиентов в приложении вместо базы данных, но также имеет гораздо большую гибкость. Поэтому вам нужно написать больше кода, но получить больше свободы. Будьте осторожны с разделением клиентов тогда, чтобы один клиент не мог просто изменить URL-адрес и получить другие продукты! Каждому запросу необходимо убедиться, что запрошенный «объект» (продукт, клиент и т. Д.) Предназначен для правильного клиента. – flaschenpost

Да, ваше предложение - это мой дизайн схемы! :). и, честно говоря, я никогда не делал резервное копирование на уровне строк. Я думал об этом позже, но я думаю, что лучше, если я знаю, прежде чем я смогу разработать свою схему, возможно, это потребует изменения в моей схеме. У вас есть какая-либо учебная ссылка или любая ссылка, где я могу это узнать? Или посоветуете меня за это? С благодарностью..! –

Предложение:

Вы можете использовать ниже подход, если подходит вам-

Держите единую базу данных для ваших производственных таблиц.

хранить все таблицы журналов в разных БД, если вам нужны журналы журналов в вашем проекте.

отдельные таблицы проекта/сайт Мудрые префиксом, как имя таблицы начнет prj1_table_name для проекта 1 и prj2_table_name для проекта 2.

По моему предположению вы хотите сохранить двигатель в InnoDB.

Так что держите innodb_file_per_table в вашем файле конфигурации.

Выгода:

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

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

источник

2015-09-11 07:39:00

Спасибо за ваше предложение, но я думаю, что я не получаю вашу точку 4 (DATABACKUP) и да, теперь я сосредоточен на одиночной БД, так как в том, что я делаю, скажу, что это будет похоже на shopify.com, но разница - это родительский сайт также будет сайтом электронной коммерции и будет иметь поисковую систему, которая вытащит запрошенный результат продукта из всех дочерних элементов, которые когда-либо были у него. (как определено в моем вопросе выше о родительском и дочернем сайте), поэтому для поиска по всем дочерним сайтам, для меня один БД проще (я не знаю, есть ли способ поиска по всем БД). –

Еще одна вещь, которую нужно задать, есть ли что-то вроде резервного копирования данных на уровне строк? Поскольку каждый дочерний объект может также делать резервную копию данных и загружать их, на самом деле я не сталкивался с этой необходимостью, прежде чем так запутался или, возможно, мне не хватает знаний об этом. Еще раз спасибо –

Что вы подразумеваете под резервными копиями на уровне строк и чего вы хотите достичь. –

MySql, несколько или разные базы данных? 1 поисковая система

ответ

Смежные вопросы