Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Оптимизация кода  [new]
danton
Member

Откуда:
Сообщений: 170
sql serv 2008R2 developer edition

Приведу кусок кода, есть у меня, например 3 таблицы с одинаковыми полями, но разными фактами внутри. (tbl_1,tbl_2,tbl_3)
И различные поля в них нужно обновлять другими таблицами, к примеру по коду.
Апдейтов получается очень много. Вот пример:
UPDATE	tbl_1
SET	tbl_1.filed_1 = Tbl_test.filed_test
FROM	Tbl_test
WHERE	Tbl_test.code = tbl_1.CODE_cost

UPDATE	tbl_2
SET	tbl_2.filed_1 = Tbl_test.filed_test
FROM	Tbl_test
WHERE	Tbl_test.code = tbl_2.CODE_cost

UPDATE	tbl_3
SET	tbl_3.filed_1 = Tbl_test.filed_test
FROM	Tbl_test
WHERE	Tbl_test.code = tbl_3.CODE_cost


Вопрос: как оптимизировать подобный код.
Я так понимаю нужно юзать динамически запросы, но что-то к апдейтам и к названиям конкретных полей применить у меня не вышло.
1 ноя 12, 16:33    [13410012]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация кода  [new]
Glory
Member

Откуда:
Сообщений: 104760
danton
Вопрос: как оптимизировать подобный код.

Вы под оптимизацией понимаете сокращение длины кода ?
1 ноя 12, 16:43    [13410092]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация кода  [new]
danton
Member

Откуда:
Сообщений: 170
Glory
Вы под оптимизацией понимаете сокращение длины кода ?

В данном случае да, в принципе еще и понимание кода.
Простите некорректно выразился - Рефакторинг кода.
1 ноя 12, 16:49    [13410145]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация кода  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
danton
sql serv 2008R2 developer edition

Приведу кусок кода, есть у меня, например 3 таблицы с одинаковыми полями, но разными фактами внутри.

[/src]

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


я могу сказать что вы можете написать процедуру с динамическим СКЛ и именем таблицы как параметр (даже рабоать будет и т. п.).
Но не буду )

У вас ошибка скорее на уровне выделения сущностей-атрибутов.

Как вы допустили одинаковые таблицы?

Давайте я вам поставлю вопрос, а вы подумаете надо ответом (который будет очевиден).

1) У вас есть большая система
2) В системе учитываются
- люди
- пациенты
- клиенты (физические лица)
- сотрудники
- ...
3) люди, сотрудники ... имеют "паспортные данные", "дату рождения", "пол" (только пол рождения - медицинский, а не паспортый).
4) Паспортные данные (ФИО) могут изменятся (но для старых сущностей, как например какой-нить "договор" необходимо сохрянять именно старые ФИО (но "текущий" только один). Разница межжу "корректировка ошибки ввода данных" и "изменением ФИО" - большая.
5) Так же надо учитывать что у человека есть документы (паспорт, военный билет,... права, справка об освобождении), они имею историю изменения, но текущий так же только один.

Как вы будите выделять сущности?

Сюда смотрим ПОТОМ
+

1) Сущность "Человек" с атрибутами ДР и Пол
2) Сущность "Паспортные данные" с атрибутами ФИО, ссылка на предыдущее ФИО, ссылка на человека, дата с которой ФИО действует (но не по ней определяем текущее). Так же человек имеет обратную ссылку на "текущее ФИО" (и на остальные атрибуты которые активны в данные момент).
3) "документ (удостоверяющийй личность)", которые ссылается на "Паспортные данные" (на который дополнительно может ссылатсья человек как на "текущий")
4) Остальные сущности (сотрудний, клиент, пациент ...) сслыаются на созданного человека

Далее при расширении сисетмы мы ссылается на необходимый тип сущности, например, в договоре мы будем ссылаться на "документ" в нём мы будем иметь и тип и его номер и те паспортные данные которые были при составлении этого "договора", но при этом "сотрудник" будет ссылаться на "человек", а следовательно мы в "списке сотрудников" или где-то ещё будем видеть его по текущим, актуальным данным.


Так вот, моё мнение что либо у вас таблицы не правильные либо это разные таблицы с очень походими названиями.
1 ноя 12, 18:44    [13410760]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация кода  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
danton
Glory
Вы под оптимизацией понимаете сокращение длины кода ?

В данном случае да, в принципе еще и понимание кода.
Простите некорректно выразился - Рефакторинг кода.


Может быть "не код надо оптимизировать".
А то часто бывают любители "список городов", "список стран", "список ...", "список статусов" хранить в разных копи-паст таблицах и т. п.
1 ноя 12, 18:46    [13410769]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация кода  [new]
danton
Member

Откуда:
Сообщений: 170
NIIIK
я могу сказать что вы можете написать процедуру с динамическим СКЛ и именем таблицы как параметр (даже рабоать будет и т. п.).


Меня это действительно интересует, если даже применять не для этой задачи.


NIIIK
У вас ошибка скорее на уровне выделения сущностей-атрибутов.
Как вы допустили одинаковые таблицы?


Знаете, отвечу и да и нет. Может будете ругаться, но все же.
Да приведенный ниже пример очевиден. И так действительно нужно строить таблицы.
Но жизнь намного веселее... Есть 3 таблицы с идентичными полями, но различными данными в них.
Каждая из них является Exchange-таблицей, куда попадают данные из 3х учетных систем (в моем случаем 1С).
Да правильно было бы дать задание 1С программистам трех разных учетных систем сливать все в 1 единую таблицу, жестко проконтролировать настройки перезаписи данных в эту таблицу.
Но было сделано не так.
И вы еще раз правы, я не буду париться с динамическим скулем, а лучше продумаю дальнейшую структуру своей базы.

NIIIK
А то часто бывают любители "список городов", "список стран", "список ...", "список статусов" хранить в разных копи-паст таблицах и т. п.


А в чем проблема хранить разные справочники и одну таблицу с ссылками на них?!
1 ноя 12, 19:00    [13410809]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация кода  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
danton
NIIIK
я могу сказать что вы можете написать процедуру с динамическим СКЛ и именем таблицы как параметр (даже рабоать будет и т. п.).



Знаете, отвечу и да и нет. Может будете ругаться, но все же.
Да приведенный ниже пример очевиден. И так действительно нужно строить таблицы.
Но жизнь намного веселее... Есть 3 таблицы с идентичными полями, но различными данными в них.
Каждая из них является Exchange-таблицей, куда попадают данные из 3х учетных систем (в моем случаем 1С).
Да правильно было бы дать задание 1С программистам трех разных учетных систем сливать все в 1 единую таблицу, жестко проконтролировать настройки перезаписи данных в эту таблицу.
Но было сделано не так.


А в чем проблема хранить разные справочники и одну таблицу с ссылками на них?!


1) один ДМЛ-опретор не будет распространятся на более чем одну таблицу в принипе
(хотя это могут быть различные типы сущностей или один тип, который родительский у нескольких типов)

2) добавить колонку указывающую на "тип, источник и т. п.", а потом можете сделать для "них" вьюхи что бы они думали что у них одна единственная

3) иногда надо несколько, но часто видно что "одно и то же раскидали за зря и ещё редакторы на фротэнде пишут отдельные"
Если видишь что у тебя получилось "две одинаковые таблицы" - уже надо "задуматься".
1 ноя 12, 19:36    [13410923]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация кода  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
NIIIK

3) иногда надо несколько, но часто видно что "одно и то же раскидали за зря и ещё редакторы на фротэнде пишут отдельные"
Если видишь что у тебя получилось "две одинаковые таблицы" - уже надо "задуматься".


Вот если бы вы в программировании увидили два одинаковых класса - вы бы задумались?
1 ноя 12, 19:37    [13410925]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация кода  [new]
danton
Member

Откуда:
Сообщений: 170
NIIIK
1) один ДМЛ-опретор не будет распространятся на более чем одну таблицу в принипе
(хотя это могут быть различные типы сущностей или один тип, который родительский у нескольких типов)

2) добавить колонку указывающую на "тип, источник и т. п.", а потом можете сделать для "них" вьюхи что бы они думали что у них одна единственная

3) иногда надо несколько, но часто видно что "одно и то же раскидали за зря и ещё редакторы на фротэнде пишут отдельные"
Если видишь что у тебя получилось "две одинаковые таблицы" - уже надо "задуматься".



Полностью со всем согласен.
Решение одинаковых таблиц было временным, а время затянулось...спасибо за внятное объяснение.
По первому пункту буду уже копаться сам для дальнейшего использования.
2 ноя 12, 03:32    [13411914]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить