SQL или MySQL

[des333]

Давно интересует вопрос, где лучше держать базу данных, на SQL или MySQL? И если использовать Mysql то нагрузка на сервер упадет?

 

[leshaJEY]

Mysql по блатнее.

Имхо.

 

[des333]

Mysql по блатнее.

Имхо.

А гемор будет переводить с sql на mysql

 

[NaN]

:dash2:
SQL - язык запросов. Не путайте с SQLite.

А гемор будет переводить с sql на mysql

Это не сложно.

 

[alexmo812]

А гемор будет переводить с sql на mysql

Kr1kuzya <= у него скриптик есть

 

[Kruzya]

Собственно, как уже и сказал @vadrozh, SQL - это язык программирования запросов, но никак не база данных. Не надо путать SQLite с SQL.
А если по теме, то у SQLite есть преимущества, как и у MySQL. Обе базы данных хороши.

А заменять SQLite на MySQL у всех плагинов подряд не стоит. Иногда лучше сидеть на SQLite, чем на MySQL.
Банальнейший пример: если использовать статистику аля RankMe только на одном сервере, и в целях нет задачи "выводить её на сайт", то имеет смысл использовать SQLite, т.к. он легче MySQL, выполняется быстрее и локально.

А ещё MySQL может крашить сервер, если сам драйвер законфликтует с ядром системы. Такое бывает. Редко, но бывает.
Это так, к сведению.
--- Добавлено позже ---
@alexmo812, у меня скрипт только для [VIP] Core 2.1.1 и Levels Ranks последних есть. Для остальных плагинов не составлял.

 

[Drumanid]

А гемор будет переводить с sql на mysql

Импорт данных с sq3(локальной базы) в MySQL

 

[Gladi[a]tor]

БД, в которую заносится каждый вошедший на сервер игрок, лучше подключать к MySQL

 

[rokfestr]

Если у тебя диск hdd то лучше использовать MySQL, быстрее будет выполнять работу чем sqlite

 

[Kruzya]

Блин, ребят, откуда Вы такой информации начитались, что лучше MySQL в плане скорости работы и хранения?
Ещё раз: если информация никуда выводиться не будет, и делиться ею сервер с другими не собирается, то лучше конечно SQLite. Он хотя бы сервер не уронит из-за нестабильного соединения до сервера БД, чем занимается MySQL.
К тому же, касательно скорости - очень спорно. Очень и очень спорно. Учитывая, что диск практически не занят особо работой во время работы сервера. Он ею занят только при смене карты и старте сервера.

Во внимание так же можно принять тот факт, что как ни крути, но "коннект" до SQLite быстрее (поинтер на базу прямо у Сурсмода хранится, он им крутит, как захочет), чем до MySQL (пинг от игрового до БД + отправка пакета сервером + чтение оного мусклом + выполнение + отдача респонса (снова пинг)).

Да и дискутировать на тему выбора БД можно бесконечно. Сколько людей - столько и мнений. Я своё высказал.

 

[rokfestr]

Блин, ребят, откуда Вы такой информации начитались, что лучше MySQL в плане скорости работы и хранения?
Ещё раз: если информация никуда выводиться не будет, и делиться ею сервер с другими не собирается, то лучше конечно SQLite. Он хотя бы сервер не уронит из-за нестабильного соединения до сервера БД, чем занимается MySQL.
К тому же, касательно скорости - очень спорно. Очень и очень спорно. Учитывая, что диск практически не занят особо работой во время работы сервера. Он ею занят только при смене карты и старте сервера.

Во внимание так же можно принять тот факт, что как ни крути, но "коннект" до SQLite быстрее (поинтер на базу прямо у Сурсмода хранится, он им крутит, как захочет), чем до MySQL (пинг от игрового до БД + отправка пакета сервером + чтение оного мусклом + выполнение + отдача респонса (снова пинг)).

Да и дискутировать на тему выбора БД можно бесконечно. Сколько людей - столько и мнений. Я своё высказал.

Я отписался из личного опыта, у меня на серверной машине стоит hdd диск, когда такие плагины как ws, gl и тд. были подключены к sqlite то фризило игроков на серверах, переключил на mysql всё работает стабильно.

 

[Reiko1231]

@rokfestr, могло быть из-за разных синтаксисов. Если писать под MySQL, но подставить SQLite, то можно получить часть либо не работающих запросов, либо крайне неэффективных.

 

[Gladi[a]tor]

Если судить логически, то SQLite должен отвечать быстрее чем MySQL - однозначно. Но я лично переносил базу с MySQL на SQLite, и не заметил вообще разницы. При большом онлайне ответ из БД приходит с задержкой в начале карты, у первых зашедших игроков. А по идее должен быть мгновенным.

 

[R1KO]

@Gladi[a]tor, тут нужно учесть ресурсы потребляемые СУБД SQLite, т.к. при работе с MySQL это перекладывается на сторонний сервер, а в случае с SQLite обработку запросов выполняет та же железяка на которой стоит игровой сервер

 

[des333]

Блин, ребят, откуда Вы такой информации начитались, что лучше MySQL в плане скорости работы и хранения?
Ещё раз: если информация никуда выводиться не будет, и делиться ею сервер с другими не собирается, то лучше конечно SQLite. Он хотя бы сервер не уронит из-за нестабильного соединения до сервера БД, чем занимается MySQL.
К тому же, касательно скорости - очень спорно. Очень и очень спорно. Учитывая, что диск практически не занят особо работой во время работы сервера. Он ею занят только при смене карты и старте сервера.

Во внимание так же можно принять тот факт, что как ни крути, но "коннект" до SQLite быстрее (поинтер на базу прямо у Сурсмода хранится, он им крутит, как захочет), чем до MySQL (пинг от игрового до БД + отправка пакета сервером + чтение оного мусклом + выполнение + отдача респонса (снова пинг)).

Да и дискутировать на тему выбора БД можно бесконечно. Сколько людей - столько и мнений. Я своё высказал.

У меня сейчас на Mysql стоит SourceBans и Level Ranks, в планах ещё добавить VIP.

Я хочу узнать, есть смысл переводить sourcemod-local.sq3, clientprefs-sqlite.sq3 на mysql. Как по мне лучше их оставить на локалке, но место много едят

 

[NaN]

Я хочу узнать, есть смысл переводить sourcemod-local.sq3, clientprefs-sqlite.sq3 на mysql. Как по мне лучше их оставить на локалке, но место много едят

Абсолютный бред. Вообще не имеет смысла этот перенос. Если упадет машина с базами, то сервер будет лежать намертво.

 

[Kruzya]

У меня сейчас на Mysql стоит SourceBans

А его можно разве на SQLite поставить? Сомневаюсь. Он здесь явно лишний упоминается.

Ещё раз: держать всё в MySQL, если у Вас всего лишь один сервер - смысла нет.