Добрый день!

Занимаюсь помаленьку проектированием БД, необходимо организовать удобную систему связей объектов бд, а также их уникальность. БД MySQL, производительность важна.

Возникли вопросы:

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

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

табл 1 (поле 1 содержит ключ на таблицы 2 и 3)
ИД Поле1
1 2_4
2 2_5
3 3_6

табл 2
ИД имя
4 Вася
5 Петя

табл 3
ИД имя
6 Маня


Думаю это можно решить используя дополнительную таблицу (с гуидом как в п1 описано).
Запросы будут выглядеть примерно так: ВЫБРАТЬ т1.ИД, вз.имя ИЗ табл1 ЛЕВОЕ СОЕД (таблсгуидом левое соединение (Табл2 объединить Табл3 )) КАК вз ПО Табл1.Поле1=вз.ИД

Результат :
ИД Имена,Прицепленные из двух таблиц
1 Вася
2 Петя
3 Маня

Такой запрос тоже не очень мне нравится.

Поделитесь опытом кто над такими вопросами уже озадачивался.)

Спасибо!

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

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

а гуид в поле с каким типом хранить? а так идея ясна.

Как быть с вопросом №2?. Не могу додумать как такие связки делать, фактически вместо 1 левого соединения надо организовать 2, причем в 1 поле. Можно с помощью "объединить" а можно левым вытащить 2 поля из разных таблиц и потом рассчитать третье, в котором будут данные из обоих таблиц, но это вообще печальный вариант.

Задача примерна такова: реализовать в проектируемой БД возможность, в реквизитах объектов указывать ИД не из конкретной таблицы, а из произвольной. В примере выше ИД может указывать на табл2 или табл3.

Подобная фишка есть в 1с.

Вот как то так

П-Л :
Согласен пример не удачный, он лишь показывает что есть и что надо получить.


iljy :
Сущности разные, но имеют что то общее. В 1с это Наименование у справочников

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

дык это от безграмотности моей) на форуме новичок ))

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

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

iljy : что то вроде первого варианта я и хочу реализовать, поэтому то и задался вопросом, "а как левое соединение делать в БД, где ссылки не на конкретную таблицу идут?".

Пока что вариант с объединением только есть у меня

если с гуидом тогда последний вариант без "AND tblMain.код = <union набор>.<конкретное значение>" можно делать.

Думаю он всяко лучше чем с кейсом. Или я не прав?

П-ЛКритерий лучшести и правильности ?

в данном случае, то что быстрее работает то для меня и лучше))

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

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


coalesce я прогуглю.

П-ЛКакова мощность данных ? Сколько будет аналогичных внешних таблиц ? При ограниченном количестве записей во внешних таблицах почему бы не сделать диапазонные автосчетчики ?

И вы все-таки не описали первоначальную задачу в бизнес-терминах. Мы обсуждаем только с ваш подход к ее решению. Не факт, что он правильный.

Мощность данных не очень большая, порядка 100 документов в день, иногда очень большие, с 1000 позиций, загрузка номенклатуры с характеристика, порядка несколько десятков тысяч. Аналогичных таблиц внешних в принципе не будет, некоторые могут иметь одинаковые поля.

Диапазонные автосчетчики честно говоря не знаю, но подозреваю что будут непонятные моменты по обмену даннымми между узлами

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

iljyЖэконНасчет ВК это да казус, целостность организовать в программе можно.

Это порочный путь
Жэкон А может можно вьхами делать? Тогда и ВК получиться если я не ошибаюсь
Вьюхами делать что?

Во вьюхе делать объединение. и на вьюху ВК цеплять. Или это тоже некашерно?