ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Работа с полем UNIQUEIDENTIFIER (sql server)
7 сообщений из 32, страница 2 из 2
  2  все
Работа с полем UNIQUEIDENTIFIER (sql server)
    #33624204
Недоходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Недоходящий
Участник
Используя CAD
...
Рейтинг: 0 / 0
24.03.2006, 16:54
| Ответить | Цитировать | Написать  
Работа с полем UNIQUEIDENTIFIER (sql server)
    #33624372
Фотография Aleksey-K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aleksey-K
Участник
НедоходящийВ дополнений меня волует то что я писал ранее. что тип UNIQUEIDENTIFIER не понимает. как заставить фокс понимать эту значения как символьные?
Что значит не понимает!?
Вот DDL таблицы на сервере:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
USE pubs

CREATE TABLE [dbo].[TEST_U] (
	[PK] [uniqueidentifier] NOT NULL ,
	[NAME] [varchar] ( 40 ) NOT NULL ,
	[KOD1] [int] NOT NULL ,
) ON [PRIMARY]

ALTER TABLE [dbo].[TEST_U] WITH NOCHECK ADD 
	CONSTRAINT [PK_TEST_U] PRIMARY KEY  CLUSTERED 
	(
		[PK]
	)  ON [PRIMARY] 

ALTER TABLE [dbo].[TEST_U] ADD 
	CONSTRAINT [DF_TEST_U_PK] DEFAULT (newid()) FOR [PK],
	CONSTRAINT [DF_TEST_U_NAME] DEFAULT ('') FOR [NAME],
	CONSTRAINT [DF_TEST_U_KOD] DEFAULT ( 0 ) FOR [KOD1]
-- Добавляем три строки
INSERT INTO TEST_U DEFAULT VALUES 
INSERT INTO TEST_U DEFAULT VALUES 
INSERT INTO TEST_U DEFAULT VALUES
Соединяемся с сервером из VFP и читаем данные из таблицы TEST_U:
Код: plaintext
1.
2.
3.
4.
5.
m.lcDSNLess="Driver=SQL Server;SERVER=Master;DBMSSOCN=TCP/IP;Trusted_Connection=Yes;APP=TEST;DATABASE=pubs"
ln = SQLSTRINGCONNECT(m.lcDSNLess)
SQLEXEC(ln, "SELECT * FROM TEST_U")
SQLDISCONNECT(ln)
BROWSE LAST
DISPLAY STRUCTURE
И что видим?
Поле PK имеет в VFP тип C(36), что вам и говорил ВладимирМ.
С уважением, Алексей.
...
Рейтинг: 0 / 0
24.03.2006, 17:43
| Ответить | Цитировать | Написать  
Работа с полем UNIQUEIDENTIFIER (sql server)
    #33624458
Sergey-D
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey-D
Гость
Я так понимаю, что Недоходящий имел ввиду использование GUID через CAD. Когда мы получаем данные, то курсоре видим С(36), но при попытке, к примеру, сделать рефреш строки после Inserta в CAD'е получаем сообщение типа: Немогу сконверитровать Charcter в GUID.
...
Рейтинг: 0 / 0
24.03.2006, 18:14
| Ответить | Цитировать | Написать  
Работа с полем UNIQUEIDENTIFIER (sql server)
    #33625532
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Korolyov
Участник
Hi Aleksey!

Лишь несколько небольших замечаний:
- Если речь идёт о сверхбольших объёмах, то очевидно нас уже не сможет
удовлетворять 4 байтный ID - скорее всего придётся переходить на bigint - а
разница между 8 и 16 байтами уже не столь "ошеломляющая". Те-же соображения
для таблиц подверженных большому траффику даных - т.е. большой объём вставок
и удалений - конечно если не "переиспользовать" Id удаляемых записей. И как
развитие темы - системы с репликацией - когда искусственно "сужается"
диапазон возможных значений ID - для обеспечения каждому узлу "своего",
индивидуального диапазона.

- Что касается индексов - далеко не всегда оптимально иметь индексы на поля
FK - это очень большая тема, просто для желающих намекну про селективность
индекса. Даже для фокса это актуально - и описано в статьях с
(под)заголовками Non-Discriminative Indexes (типичный пример - индекс по
DELETED() или по логическому полю, или по полю типа "пол") в общем ИНОГДА
выгоднее просмотреть всю таблицу целиком, нежели осуществлять доступ через
индексный файл.

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
26.03.2006, 00:20
| Ответить | Цитировать | Написать  
Работа с полем UNIQUEIDENTIFIER (sql server)
    #33626280
Фотография Aleksey-K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aleksey-K
Участник
Igor Korolyov
Hi Aleksey!

Лишь несколько небольших замечаний:
- Если речь идёт о сверхбольших объёмах, то очевидно нас уже не сможет
удовлетворять 4 байтный ID - скорее всего придётся переходить на bigint - а
разница между 8 и 16 байтами уже не столь "ошеломляющая".

Я думаю, что INTEGER на долго хватит.
Если раз в секунду будете добавлять запись, то хватит на непрерывную работы в течении 68 лет!

Igor Korolyov
- Что касается индексов - далеко не всегда оптимально иметь индексы на поля
FK - это очень большая тема, просто для желающих намекну про селективность
индекса.

Индекс ВСЕГДА полезен для FK - даже если его селективнасть низкая, то:
1. Оптимизатор запроса просто не будет его использовать.
2. Сегодня индекс не нужен, а завтра.... уже нужен - пусть индекс будет, а оптимизатор решит сам, надо или не надо.
С уважением, Алексей.
...
Рейтинг: 0 / 0
27.03.2006, 09:24
| Ответить | Цитировать | Написать  
Работа с полем UNIQUEIDENTIFIER (sql server)
    #33633915
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Korolyov
Участник
Hi Aleksey!

> Я думаю, что INTEGER на долго хватит.

Зависит от массы факторов - я лишь привёл наиболее общие проблемы - в
частности введение "групп/диапазонов для репликации" - которые в десятки (а
иногда и в сотни) раз уменьшают "полезный" диапазон int-поля.

> Индекс ВСЕГДА полезен для FK - даже если его селективнасть низкая, то:
> 1. Оптимизатор запроса просто не будет его использовать.

Хороший конечно не будет - если ему дать всю необходимую информацию для
принятия правильного решения, что кстати не всегда выполняется. Но проблема
не в этом, а в том что ЛЮБОЙ индекс необходимо поддерживать в актуальном
состоянии - т.е. чем больше индексов, тем "тяжелее" все операции изменения
данных! С этой точки зрения "лишние индексы" - это зло.

> 2. Сегодня индекс не нужен, а завтра.... уже нужен - пусть индекс будет, а
> оптимизатор решит сам, надо или не надо.

Вопрос о необходимости подобных индексов в "правильных" системах решает DBA
(причём часто гораздо позже чем внедрение программы!) или разработчик
приложения (если он компетентен в особенностях работы конкретной версии
СУБД - т.к. тут очень многое зависит от работы оптимизатора). И тут никаких
"rule of dumb" нет и быть не может! Ну разве что СПЕЦИАЛЬНО заложить в
систему разнообразные камешки, чтобы задать "на потом" много работы DBA по
оптимизации этой системы :)

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
30.03.2006, 02:46
| Ответить | Цитировать | Написать  
Работа с полем UNIQUEIDENTIFIER (sql server)
    #33634089
Фотография Aleksey-K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aleksey-K
Участник
Igor Korolyov
Hi Aleksey!
Зависит от массы факторов - я лишь привёл наиболее общие проблемы - в
частности введение "групп/диапазонов для репликации" - которые в десятки (а
иногда и в сотни) раз уменьшают "полезный" диапазон int-поля.

Согласен, но я говорю про свой опыт. У меня пока не было потребности в большей размерности поля для PK, чем INTEGER.
Igor Korolyov
Хороший конечно не будет - если ему дать всю необходимую информацию для
принятия правильного решения, что кстати не всегда выполняется. Но проблема
не в этом, а в том что ЛЮБОЙ индекс необходимо поддерживать в актуальном
состоянии - т.е. чем больше индексов, тем "тяжелее" все операции изменения
данных! С этой точки зрения "лишние индексы" - это зло.
....
Вопрос о необходимости подобных индексов в "правильных" системах решает DBA
(причём часто гораздо позже чем внедрение программы!) или разработчик
приложения (если он компетентен в особенностях работы конкретной версии
СУБД - т.к. тут очень многое зависит от работы оптимизатора). И тут никаких
"rule of dumb" нет и быть не может! Ну разве что СПЕЦИАЛЬНО заложить в
систему разнообразные камешки, чтобы задать "на потом" много работы DBA по
оптимизации этой системы :)

Тоже согласен, но иногда такие DBA встречаются у заказчиков, что.... .. мда..
Но в общем случае, если есть FK, то где-то у нас обязательно встретиться запрос, который будет иметь JOIN между этим FK и соответс. PK.
Поэтому, я ВСЕГДА создаю индекс по FK, так как MERGE JOIN мне больше нравится, чем HASH или NESTED LOOP :).
А оптимизация чтения, более сложная операция, что записи (обновления).
Так что я стараюсь оптимизировать именно чтение.
С Уважением, Алексей
...
Рейтинг: 0 / 0
30.03.2006, 09:01
| Ответить | Цитировать | Написать  
7 сообщений из 32, страница 2 из 2
  2  все
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Работа с полем UNIQUEIDENTIFIER (sql server)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=41&gotonew=1&tid=1592018]:
 0ms
get settings:
 7ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 83ms
get topic data:
 8ms
get first new msg:
 5ms
get forum data:
 2ms
get page messages:
 32ms
get tp. blocked users:
 1ms
others: 240ms
total:  399ms
созд. / загр.: 399ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]