SqlServer составляют таблицу с MySql как auto_increment первичный ключ
Я попробовал вышеуказанное решение, но я счел его непригодным для больших объемов данных. Затем я обнаружил функцию потока:
MongoClient.connect("...", function(err, db){
var c = db.collection('yourCollection');
var s = c.find({/* your query */}).stream();
s.on('data', function(doc){
c.update({_id: doc._id}, {$set: {name : doc.firstName + ' ' + doc.lastName}}, function(err, result) { /* result == true? */} }
});
s.on('end', function(){
// stream can end before all your updates do if you have a lot
})
})
8 ответов
Как это
create table foo
(
user_id int not null identity,
name varchar(50)
)
Они ответили на Ваш вопрос, но я хочу добавить один совет для кого-то плохо знакомого с использованием столбцов идентификационных данных. Существуют времена, когда необходимо возвратить значение идентификационных данных, просто вставленных так, чтобы можно было вставить в связанную таблицу. Много источников скажут Вам использовать @@ идентификационные данные для получения этого значения. Ни при каких обстоятельствах не должны Вы когда-либо использовать @@ идентификационные данные, если Вы хотите поддержать целостность данных. Это даст идентификационные данные, созданные в триггере, если один из них будет добавлен для вставки в другую таблицу. Так как Вы не можете гарантировать значение @@, идентификационные данные всегда будут корректны, лучше никогда не использовать @@ идентификационные данные. Используйте scope_identity () для получения этого значения вместо этого. Я знаю, что это немного вне темы, но для Вашего понимания того, важно, как использовать идентификационные данные с SQL Server. И доверяйте мне, Вы не хотели решать проблему связанных записей, имеющих неправильное значение идентификационных данных, питаемое им. Это - что-то, что может бесшумно пойти не так, как надо в течение многих месяцев, прежде чем это будет обнаружено и будет почти невозможно зафиксировать данные позже.
OP запросил автоматический увеличенный первичный ключ. Ключевое слово ИДЕНТИФИКАЦИОННЫХ ДАННЫХ, отдельно, не заставляет столбец быть первичным ключом.
CREATE TABLE user
(
TheKey int IDENTITY(1,1) PRIMARY KEY,
Name varchar(50)
)
Поскольку другие упомянули: добавьте, что ИДЕНТИФИКАЦИОННЫЕ ДАННЫЕ приписывают столбцу и делают его первичным ключом.
Существуют, однако, различия между ИДЕНТИФИКАЦИОННЫМИ ДАННЫМИ MSSQL и AUTO_INCREMENT MySQL:
- MySQL требует, чтобы ограничение на уникальность данных (часто в форме первичного ключа) было определено для столбца AUTO_INCREMENT.
MSSQL не имеет такого требования. - MySQL позволяет Вам вручную вставить значения в столбец AUTO_INCREMENT.
MSSQL предотвращает Вас от ручной вставки значения в столбец IDENTITY; в случае необходимости можно переопределить это путем давания команды "SET IDENTITY_INSERT tablename ON" перед вставкой. - MySQL позволяет Вам обновлять значения в столбце AUTO_INCREMENT.
MSSQL отказывается обновлять значения в столбце IDENTITY.
Как рекомендуется выше, используйте поле IDENTITY.
CREATE TABLE foo
(
user_id int IDENTITY(1,1) NOT NULL,
name varchar(50)
)
Поскольку другие сказали, просто установили опцию Identity.
Просто установите поле как поле идентификационных данных.