Артём Каретников

Процедура? :)

Доброго.

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

1. Эти поля у вас наверняка в запросах участвовать не будут, ни индексов, ни оптимизации им просто не нужно.
2. На выборку данных из них, если она все же потребуется, например, для создания описания базы, нужны будут запросы похитрей. На их создание и на реализацию всего, кроме первого варианта - потребуется время, которое лучше пустить на разработку базы
3. Все эти хитрые запросы не будут восприняты ни одной системой автоматической генерации описаний.
4. Вряд ли описания настолько часто совпадают и их настоль много, что оптимизация их ускорит выборку.

В общем, овчинка выделки не стоит, коллега.

Я бы развел в два разных поля, если уж желается максимальной производительности. Тогда понять, сколько за, сколько против - простой суммой можно будет, да. Но если со всей прямотой - можно и в одном поле типа инт хранить оба типа, пренебрежимо мала будет разница. Хранить сумму не надо, ее дешевле посчитать. За: 1, против -1, нормально.
А вот дальше - ну, как минимум пригодится айпишник, чтобы одному не давать голосовать несколько раз, да? Еще одно поле.
Если есть необходимость хранить данные их соцсетей, а сейчас модно хранить вообще все про юзера, то еще поле под ссылку на соцсеть и второе - на тип этой сети. Итого:

rid (Pkey), u_vote, u_ip, u_soc_net, u_soc_net_type.

Индекс только на поле u_vote в рамках данной задачи. Если нужна будет выборка по соц.сетям - то индекс на тип соцсети.

Повредиться база акцесса может отчего угодно, увы. Бекапить надо.
Помочь может следующее:
1. Создаете новую базу акцесса.
2. Правой кнопкой или в меню импорта - импортировать таблицы.
3. Указываете путь к этой вашей поврежденной базе.

Если сам акцессс что-то найдет - то покажет, что найдено.

То, что голова идет кругом - вернейший признак того, что нет бизнес-требований. В идеале, за такую базу не нужно браться вообще - это прямой путь к увольнению. "Вот нам надо было, а Павел сделал все не так, а нам надо было так!"

Ну и попытка объять необъятное тут. Мега-учет в одно лицо? Не надейтесь справиться, никто это в одиночку не делает. Вот это все "количество сотрудников в комнате", "количество лифтов" - крайне сомнительно, что это вообще нужная информация.

Мои рекомендации: сесть и спокойно подумать о чем-то другом. Пару дней. Понять реальные требования в их минимальном масштабе. Конкретизировать их. Не спешите думать о структуре.

Нужен учет сотрудников в организации - это уже отдельная база данных. Нужен учет материальных средства - это еще одна отдельная база данных. И так далее.
И заметьте - на рынке есть решения этих вопросов, но нет монополиста и есть масса самописных решений. Это о чем говорит? Еще раз о том, что универсального решения нет, но есть методы для _конкретных_ задач.

То, что у вас делает запрос, означает следующее:

Для поля STAMP
возьми значение из поля [NotifyManagerTimestamp]
Поэтому и ошибка. Вам о ней и пишут: поле такое не найдено. Если вы хотите использовать переменную, то это вот так: @NotifyManagerTimestamp

Если полная модель восстановления - то все можно. Надо как можно быстрей сделать бекап лога в восемь разных мест. Откуда уверенность, что ldf не поврежден? Он лежал на другом диске? Как повредился mdf?
Размер базы какой, что именно нужно вытянуть, ее всю или ограничиться какими-то таблицами? Мало информации, стоит изложить поподробней.

Она ведь не сама по себе появляется, правда? Т.е вы как минимум открываете форму
Что показывает эта форма в дизайнтайме? Какие ссылки видны в references?

Доброго. Рыбу я не дам, дам удочку.
Обновление одного - это событие. Alter Update
Соответственно, в это событие следует написать присвоение/обновление данных для второго элемента.
Данные селектом получить можете? Вот и присваивайте этот набор записей текстовому полю.

Начинать крайне рекомендовал бы по Груберу, "понимание SQL"
Простая, с хорошими примерами - но только надо брать бумажную, вычитанную, в сети гуляет версия с кучей опечаток.

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

Все поля интовые и флоат? Не надо ничего нормализовывать, у вас и так все хорошо. Индексы по нужным запросам и все.

Конечно, можно. Почитайте про триггеры DDL.