MySQL таблица с 40+ столбцами

Question

У меня есть 40+ столбцов в моей таблице, и я должен добавить несколько полей, таких как, текущий город, родной город, школа, работа, универ, коллаж ..

Этих пользовательские данные Виля вытащил для многих подходящих пользователей, которые являются общими друзьями (присоединяются к таблице друзей с другим пользователем, чтобы видеть общих друзей), и кто не заблокирован, а также кто еще не является другом с пользователем.

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

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

ERD Диаграмма:

• Моя текущая таблица: http://i.stack.imgur.com/KMwxb.png
• Если я присоединиться к нескольким таблицам: http://i.stack.imgur.com/xhAxE.png

Некоторые предложения

1. ничего плохого в этой таблице и столбцах
2. не следовать этому подходу MySQL: Optimize table with lots of columns - который упорядочивание дополнительных полей в одно поле, которые не являются для поиска-х
3. создать еще одну таблицу и положить большую часть данных там. (Это становится все труднее, на соединения, если у меня уже есть 3 или более таблиц, чтобы присоединиться тянуть записи для пользователей (бывших друзей, пользователь, проверьте общих друзей)

Answer 1

Как обычно. - это зависит

. Во-первых, есть maximum number of columns MySQL can support, и вы действительно не хотите туда добраться.

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

В-третьих, большие столы часто являются свалками для всех данных, которые, по-видимому, связаны с основной сущностью; это быстро делает дизайн неясным. Например, представленный вами дизайн показывает 3 разных типа типа «статус» (статус, is_admin и fb_account_verified). Я подозреваю, что есть какая-то бизнес-логика, которая должна связывать их вместе (например, администратор должен быть проверенным пользователем), но ваш дизайн не поддерживает это.

Это может быть или не быть проблемой - это более концептуальный, архитектурный/дизайнерский вопрос, чем производительность/будет ли это работать. Однако в таких случаях вы можете подумать о создании таблиц, чтобы отразить соответствующую информацию об учетной записи, даже если у нее нет отношения x-to-many. Таким образом, вы можете создать «user_profile», «user_credentials», «user_fb», «user_activity», все связанные с user_id. Это делает его более аккуратным, и если вам нужно добавить больше связанных с facebook полей, они не будут болтаться в конце таблицы. Тем не менее, это не сделает вашу базу данных более быстрой или масштабируемой. Стоимость объединений, вероятно, будет незначительной.

Независимо от того, что вы делаете, вариант 2 - сериализация «редко используемых полей» в одно текстовое поле - ужасная идея. Вы не можете проверить данные (так что даты могут быть недействительными, могут быть указаны номера, а не нули), и любое использование в предложении «где» становится очень медленным.

Популярной альтернативой является «Объект/Атрибут/Значение» или «Ключ/Значение». Это решение имеет некоторые преимущества - вы можете хранить свои данные в реляционной базе данных, даже если ваша схема изменяется или неизвестна во время разработки. Однако у них также есть недостатки: трудно проверить данные на уровне базы данных (тип данных и нулеустойчивость), трудно сделать значимые ссылки на другие таблицы, используя отношения внешних ключей, и запрос данных может стать очень сложным - представьте себе все записи, где статус равен 1, а facebook_id - null, а дата регистрации больше, чем вчера.

Учитывая, что вы, как представляется, знаете схему своих данных, я бы сказал, что «ключ/значение» не является хорошим выбором.

Answer 2

У меня есть общий комментарий для вас,

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

Ваш подход в 3 таблицах кажется лучше, чем подход в 1 таблице, но подумайте о том, чтобы сделать их в 5-6 таблицах, а не в 3 таблицах, потому что вы все еще можете.

Move currently, currently_position, currently_link из user-table и work из user-profile в новую таблицу с первичным ключом называется USERWORKPROFILE.

Информация о переходе от user-profile к новому USERPROFILELOCALE информации, поскольку она носит общий характер.

И да, все ваши общие атрибуты во всех таблицах должны быть int, а не varchar. Например, Сити должен перейти в новый стол под названием LIST _OF_CITIES с cityid. И ваш атрибут city должен измениться с varchar на int и на cityid в LIST_OF_ CITIES.

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

Answer 3

Я бы посоветовал провести некоторые тесты. Попробуйте в обоих направлениях и сравните его. Никто не сможет дать вам окончательный ответ, потому что вы не поделились своей конфигурацией оборудования, образцами данных, примерами запросов, тем, как вы планируете использовать данные и т. Д. Вот некоторая информация, которую вы можете рассмотреть.

использовать базу данных, как было задумано

реляционная база данных предназначена специально для обработки данных. Используйте его как таковой. При правильном написании, соединение данных в хорошо написанной схеме будет хорошо работать. Вы можете использовать EXPLAIN для оптимизации запросов. Вы можете регистрировать SLOW-запросы и улучшать их производительность. Базы данных существуют уже много лет, если все в одном столе повысить производительность, разве вы не думаете, что это будет весь шум в Интернете, и все будут делать это?

Типы двигателей

Как вставки влияет как количество строк растет? Вы используете MyISAM или InnoDB? Скорее всего, вы захотите использовать InnoDB, чтобы получить блокировку на уровне строк, а не таблицу. Убедитесь, что для таблиц используется правильный тип двигателя. Получите информацию, необходимую для понимания плюсов и минусов обоих. Неверный тип двигателя может привести к снижению производительности.

Повышение эффективности использования Перегородки

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

Используйте типы столбцов правильно

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

Не сериализовать данные

Использования сериализованных данных хуже путь. Когда вы используете сериализованные поля, вы в основном используете базу данных в качестве системы управления файлами. Он сохранит и загрузит «файл», но тогда ваш код будет отвечать за неэриализацию, поиск, сортировку и т. Д. Я просто потратил год, пытаясь разгадать такой беспорядок. Это не то, для чего предназначалась база данных. Любой, кто советует вам это сделать, не только дает вам плохие советы, они не знают, что делают. Очень мало случаев, когда вы использовали бы сериализованные данные в базе данных.

Заключение

В конце концов, вы должны принять окончательное решение. Просто убедитесь, что вы хорошо осведомлены и хорошо осведомлены о плюсах и минусах того, как вы храните данные. Последний совет, который я бы дал, это выяснить, что делают тяжелые пользователи mysql. Как вы думаете, они хранят данные в одной таблице? Или они создают реляционную модель и используют ее так, как она была разработана для использования?

Когда вы говорите: «Я собираюсь положить все в одну таблицу», вы говорите, что знаете больше о производительности и можете сделать лучший выбор для оптимизации в своем коде, чем команда разработчиков, которые постоянно работают на MySQL, чтобы сделайте это сегодня. Подумайте о том, как взвешивать свои знания с накопленными знаниями команды MySQL и администраторов баз данных, компаний и членов сообщества баз данных, которые используют его каждый день.

Answer 4

В определенный момент вы должны посмотреть на «модель коротких строк», также знать, как хранилища значений сущностей-ключей, а также традиционную «модель с длинными рядами».

Если вы посмотрите на схему, используемую WordPress, вы увидите, что есть таблица wp_posts с 23 столбцами и связанная таблица wp_post_meta с 4 столбцами (meta_id, post_id, meta_key, meta_value). Мета-таблица - это таблица «коротких строк», которая позволяет WordPress иметь бесконечную коллекцию атрибутов для сообщения.

Ни лучшая модель, ни модель «коротких строк», зачастую лучший выбор - это сочетание двух.Поскольку @nevillek указал, что поиск и проверка «короткой строки» непросто, выборка данных может включать в себя поворот, который раздражает в MySql и Oracle.

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

Недавно я работал над системой финансовых услуг, которая имела более 700 возможных фактов для каждого инструмента, в большинстве случаев было менее 20 фактов. Это можно было бы построить, настроив десятки таблиц, каждый для определенного класса активов, или как таблицу с 700 столбцами, но мы решили использовать комбинацию таблицы с примерно 20 столбцами, содержащими самые популярные факты и 4 столбца в которой содержатся другие факты. Эта конструкция была эффективной, но была затруднена для доступа, поэтому мы создали несколько функций таблицы в PL/SQL, чтобы помочь в этом.