Контакт с циклической ссылкой при вводе данных в SQL
Для Windows Phone 8.1 используйте NuGet, чтобы добавить пакет Microsoft Compression в свой проект и сослаться на него.
Если у вас был более старый проект WP8, возможно, вы использовали другой пакет, который создавал бы конфликты с dll System.IO.Compression, который является частью .NET 4.5, поставляемой с WP8.1. Вам нужно избавиться от этого и использовать Microsoft Compression, которая гармонично работает с .NET 4.5. Вот как я сюда попал!
9 ответов
Вы особенно разбираетесь в 64-битной Java 1.4? Я пробовал использовать 32-битную Java 1.4, и она работает. Я сгруппировал веб-приложение, чтобы использовать более 2 ГБ памяти.
)Oracle разрешил определять ограничения внешнего ключа как ОТЛОЖЕННЫЕ как минимум на десятилетие. Я определяю все ограничения внешнего ключа (как само собой разумеющееся) как ОТЛОЖЕННЫЕ НА ПЕРВОНАЧАЛЬНО НЕМЕДЛЕННОМ. Это сохраняет поведение по умолчанию, как все ожидают, но позволяет манипулировать без отключения внешних ключей.
см. AskTom: http://www.oracle.com/technology/oramag/oracle/03-nov/ o63asktom.html
см. AskTom: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10954765239682
см. также: http://www.idevelopment.info/data/Oracle/DBA_tips/Database_Administration/DBA_12.shtml
[EDIT]
A: В Microsoft SQL Server нельзя откладывать ограничения внешнего ключа, как в Oracle. Отключение и повторное включение ограничения внешнего ключа - это подход, но я содрогаюсь от перспективы 1) воздействия на производительность (ограничение внешнего ключа проверяется для ВСЕЙ таблицы при повторном включении ограничения), 2) обработки исключения, если (когда?) повторное включение ограничения не удается. Обратите внимание, что отключение ограничения повлияет на все сеансы, поэтому, пока ограничение отключено, другие сеансы потенциально могут вставлять и обновлять строки, что приведет к сбою повторного включения ограничения.
Для SQL Server лучшим подходом является удаление NOT NULL, и разрешить NULL в качестве временного заполнителя, пока строки вставляются / обновляются.
Для SQL Server:
-- (with NOT NULL constraint removed from Departments.EmployeeID)
insert into Departments values ('foo',NULL)
go
insert into Employees values ('bar','foo')
go
update Departments set EmployeeID = 'bar' where DepartmentID = 'foo'
go
[/ EDIT]
I Предположим, ваши Departments.EmployeeID - руководитель отдела. Я бы сделал этот столбец допускающим значение NULL;
Выполните рефакторинг схемы, удалив циклическую ссылку.
Удалите столбец идентификатора из любой схемы таблицы.
Departments.EmployeeID , по-моему, там не место.
Я не могу придумать нехакерский способ сделать это. Я думаю, вам нужно будет удалить ограничение или сделать какие-то глупые фиктивные значения, которые обновляются после всех вставок.
Я бы рекомендовал провести рефакторинг схемы БД. Я не могу придумать никаких причин, по которым вы бы хотели, чтобы это работало именно так.
Может быть, что-то вроде Employee, EmployeeDepartment (EmployeeId, DepartmentId) и Department было бы лучшим способом достижения той же цели.
Вам нужно навсегда избавиться от той или иной ссылки. Это нежизнеспособная конструкция. Что нужно ввести в первую очередь? Отдел или сотрудник? Если все ваши отделы не состоят из одного большого сотрудника, такая структура в любом случае не имеет смысла, поскольку у каждого сотрудника должен быть отдельный отдел.
Да, в этом случае вам придется отключить внешний ключ.
Я использовал несколько хороших дизайнов. Все включают удаление «менеджера» EmployeeID из таблицы Department и удаление DepartmentID из таблицы Employee. Я видел пару ответов, в которых упоминается об этом, но поясню, как мы его использовали:
Я обычно получаю таблицу связей EmployeeDepartment - многие ко многим, обычно с такими флагами, как IsManager, IsPrimaryManager, IsAdmin, IsBackupManager и т. д., которые проясняют отношения. Некоторые могут быть ограничены так, что для каждого отдела разрешен только один основной менеджер (хотя человек может быть PrimaryManager для нескольких отделов). Если вам не нравится одна таблица, вы можете иметь несколько таблиц: EmployeeDepartment, ManagerDepartment и т. Д., Но тогда у вас могут быть ситуации, когда человек является менеджером, а не сотрудником,
Эту проблему можно решить с помощью отключаемых ограничений. Такие ограничения проверяются, когда вся транзакция фиксируется, что позволяет вам вставить в одну транзакцию и сотрудника, и отдел, ссылаясь друг на друга. (Предполагая, что модель данных имеет смысл)
Вы можете создать строку в таблице Department для 'Unassigned'
Чтобы создать новый отдел с новым сотрудником, вы должны
- Создать сотрудника (EmployeeA) в «Неназначенном»