Добрый день!

 

Еще со времен использования IBR с их "наработками" и исправлениями у меня в базе висят разные таблицы, которых нет в оригинальной поставке, настройки в ACP на русском языке, которые не несут никакого смысла и пр.

 

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

 

Если есть советы - расскажите, буду благодарен!

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

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

 

Как правильнее хотя бы удалить настройки из АЦ, оставшиеся от ИБР? Нужно ведь выяснить, что они точно нигде не используются, как минимум.

Особенно учитывая, что лишние поля и индексы могут в будущем сильно влиять на производительность.

Лишние поля и индексы чужих таблиц ничем не мешают производительности. Конечно, если у вас таблицы не занимают по 1GB+.

 

 

Как правильнее хотя бы удалить настройки из АЦ, оставшиеся от ИБР? Нужно ведь выяснить, что они точно нигде не используются, как минимум.

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

Лишние поля и индексы чужих таблиц ничем не мешают производительности. Конечно, если у вас таблицы не занимают по 1GB+.

 

Понятно, что лишние таблицы не мешают, но индексы могут быть добавлены и в активные таблицы, как и лишние поля.

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

siv1987, вопрос не в эффективности, производительности, целесообразности и пр., а в правильном способе очистке БД.

@Bonov, а что вы понимаете под "правильный способ"?

@Bonov, а что вы понимаете под "правильный способ"?

Удаление ненужных данных, которые были добавлены и не удалены сторонними приложениями, хуками, ИБР и пр., не нарушающее работу форума и всех его приложений.

Самый верный вариант выполнить поиск по скрипту - есть где-то к ним обращение или нет.

Во вложении файл сравнения структур баз данных (моего форума и чистой установки). Версия 3.4.0.

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

 

P.S. Странно, что при обновлениях типы этих полей не изменились. Либо же это все-таки наследство ИБР.

 

Различия в базах данных.rar

Странно, что при обновлениях типы этих полей не изменились. Либо же это все-таки наследство ИБР.

Зря вы все списываете на IBR. Базы обновленного с предыдущих версий (в том числе и IPS-овского) форума и нового форумов действительно отличаются, потому что при апрейде выполняются только значимые измненеия в структуре таблиц и полей.

 

Например, в вашей таблице есть несколько групп вообще не имеющих значения изменений, как то:

 

• Type: int(10) -> int(11) - сыграет роль только после 2038 года, при условии, что технологии не изменятся и все ОС будут минимум 64-битными,
  
• Default: None -> Empty string - вообще не играет никакой роли, просто "красоту навели",
  
• Attributes: UNSIGNED - аттрибут для экономии места и наращивании диапазона значений. В текущих условиях вообще ни на что не влияет.
  

 

Помимо них остается 2 изменения типа:

 

core_like	like_lookup_area	Type	char(32)	varchar(32)
core_sys_cp_sessions	session_member_name	Type	varchar(250)	varchar(255)

Тут char заменен на varchar отказа от экономии пары байт ради "крастоы" места, и varchar(250) на varchar(255) просто для красоты, чтобы уже везде было 255 (хотя там хватит и 16 символов, т.к. там хранятся 16-символьные сессии).

 

Новые дефолтные настройки для галереи:

groups	g_photo_max_vars	Default	100:150:150	100:200:300

 

Подписка на уведомления включена по-фелоту:

inline_notifications	notify_meta_id	Null	Yes	No

 

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

members	blogs_recache	Extra field	

 

Тентаклеговно от IBR:

members	vk_uid	Extra field	

 

Исторически сохранилось из формы регистрации 3.1.х-, не используется:

members	ip_address	Default	

 

Когда-то у постов были заголовки и иконки:

posts	post_title	Extra field
posts	icon_id	Extra field	

 

А к провилям пользователей можно было писать заметки:

profile_portal	notes	Extra field	

 

У топиков тоже были описания и иконки:

topics	description	Extra field
topics	icon_id	Extra field

 

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

 

Заключение: при обновлениях IPS придерживается концепции "максимального сохранения" данных. То, что важно для работоспособности и скорости - то изменяется. Исторически сохранившиеся данные - хранятся и дальше, "а то мало ли что". Никакой необходимости что-то чистить вручную нет. Все важные для скорости и работы типы и индексы так же меняются и переустанавливаются мастером обновления.

Ritsuka, спасибо, теперь все понятно, что к чему, и переживания оказались бессмысленными. Зато теперь я владею важной информацией, которая может пригодиться в будущем! ;)