Выбор структуры базы данных. Нужно ваше мнение

@ПАЦАН · Регистрация: 04.01.2010

Студворк — интернет-сервис помощи студентам

всем привет. скоро намечается проект с большой посещаемостью, и возник вопрос, как лучше организовать структуру таблиц. допустим, есть возможность отправлять сообщения, добавлять в друзья и т.д. что лучше, создавать таблицы одни для всех, тоесть messages, friends и т.д. и хранить в них записи для всех пользователей, или создавать отдельные таблицы для каждого пользователя при регистрации, тоесть messages_[id юзера], friends_[id юзера] и т.д. плюс второго варианта - быстродействие. легче перебрать сотню другую записей чем несколько тысяч а то и миллионов. плюс первого варианта - минимум таблиц и проще структура. в старых проектах я использовал и тот и другой вариант. сейчас хочу знать ваше мнение, какой вариант выбрали бы лично вы. но для меня приоритет - быстродействие.

@DuxGeneral · 05.02.2012, 02:36

Сообщение от ПАЦАН

но для меня приоритет - быстродействие

В чем проблема?

@vasvas7775 · 05.02.2012, 07:41

Зачем много таблиц??
А если у вас пользователей 500000 , это что стока таблиц???

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

Короче если правильно составлять запросы, все будет работать нормально.

Новые блоги и статьи Все статьи Все блоги /
Автоматическое создание документа при проведении другого документа Maks 29.03.2026 Реализация из решения ниже выполнена на нетиповых документах, разработанных в конфигурации КА2. Есть нетиповой документ "ЗаявкаНаРемонтСпецтехники" и нетиповой документ "ПланированиеСпецтехники". В. . .	Настройка движения справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .	Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .
Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .	Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .	Отправка уведомления на почту при создании или изменении элементов справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной записи электронной. . .

@ПАЦАН 45 / 45 / 12 Регистрация: 04.01.2010 Сообщений: 223

	Выбор структуры базы данных. Нужно ваше мнение 05.02.2012, 02:21. Показов 1241. Ответов 2 Метки нет (Все метки) всем привет. скоро намечается проект с большой посещаемостью, и возник вопрос, как лучше организовать структуру таблиц. допустим, есть возможность отправлять сообщения, добавлять в друзья и т.д. что лучше, создавать таблицы одни для всех, тоесть messages, friends и т.д. и хранить в них записи для всех пользователей, или создавать отдельные таблицы для каждого пользователя при регистрации, тоесть messages_[id юзера], friends_[id юзера] и т.д. плюс второго варианта - быстродействие. легче перебрать сотню другую записей чем несколько тысяч а то и миллионов. плюс первого варианта - минимум таблиц и проще структура. в старых проектах я использовал и тот и другой вариант. сейчас хочу знать ваше мнение, какой вариант выбрали бы лично вы. но для меня приоритет - быстродействие. 0

@vasvas7775 Обитатель 539 / 317 / 42 Регистрация: 24.12.2010 Сообщений: 795
	05.02.2012, 07:41
	Зачем много таблиц?? А если у вас пользователей 500000 , это что стока таблиц??? Одна таблица и там все пользователи. Нужного нашли по логину, и по этой строчке уже выбираем данные...... Короче если правильно составлять запросы, все будет работать нормально. 1