Красотки ничего не производят, кроме смазливого впечатления.
Вопрос довольно глупый, возможно, с точки зрения программистов языка sql и администраторов БД.
Чем отличается создание запросов, таблиц и всего остального в конструкторе/мастере, т. е. средствами самого access от написания алгоритмов по созданию этого же всего через sql. Понятно, конечно, что 1-й способ быстрее, понимать надо всё же не алгоритм, который выдаёт результат, а правильные.. ограничения, рамки, цели в том, что мы хотим видеть. Понятно, что во 2-м случае мы понимаем сам алгоритм, т. е. средство объяснить компьютеру в рамках данной программной оболочки, что мы от него хотим, и с некоторыми ограничениями и средствами, связанными с другой программной оболочкой, мы можем использовать 1 и тот же алгоритм в рамках этой другой программной оболочки. Но есть ли различия в самом алгоритме? Есть ли какие-то преимущества и недостатки в способах, кроме вышеописанных? Преподаватель мне про запросы 1-м методом сказал, что это с точки зрения sql неправильно. Т. е. с точки зрения теории?
В общем, возможно, что-то я не так понял, что-то написал некорректно, но пишу как понимаю.
Если это лучше объяснено в литературе - с удовольствием ознакомлюсь со списком авторов.Пусть, может, через нек. время после сдачи экзамена по этому предмету
Чем отличается создание запросов, таблиц и всего остального в конструкторе/мастере, т. е. средствами самого access от написания алгоритмов по созданию этого же всего через sql. Понятно, конечно, что 1-й способ быстрее, понимать надо всё же не алгоритм, который выдаёт результат, а правильные.. ограничения, рамки, цели в том, что мы хотим видеть. Понятно, что во 2-м случае мы понимаем сам алгоритм, т. е. средство объяснить компьютеру в рамках данной программной оболочки, что мы от него хотим, и с некоторыми ограничениями и средствами, связанными с другой программной оболочкой, мы можем использовать 1 и тот же алгоритм в рамках этой другой программной оболочки. Но есть ли различия в самом алгоритме? Есть ли какие-то преимущества и недостатки в способах, кроме вышеописанных? Преподаватель мне про запросы 1-м методом сказал, что это с точки зрения sql неправильно. Т. е. с точки зрения теории?
В общем, возможно, что-то я не так понял, что-то написал некорректно, но пишу как понимаю.
Если это лучше объяснено в литературе - с удовольствием ознакомлюсь со списком авторов.Пусть, может, через нек. время после сдачи экзамена по этому предмету
-
-
22.01.2012 в 19:55Ну то есть она, вроде как, самоочевидна — окошечки для тех, кому лень писать руками код, но поработать с данными хочется. Соответственно, если что-то не учли при создании красивых окошечек — это ещё не значит, что это вообще невозможно сделать, если писать вручную. Как-то так.
Впрочем, сам я редко когда при создании/модификации таблиц (нет, речь не про MS Access) руками пишу «CREATE TABLE…» — т.к. потыкать галочки/покрутить выпадающие списки и всё такое — обычно проще, быстрее и надёжнее.
-
-
22.01.2012 в 21:24Ну главное - в профессиональной работе что чаще используется и почему?
-
-
22.01.2012 в 22:53А в целом — создавать и изменять таблицы голым кодом, имхо, не круто и вообще странно, если такая необходимость возникает не на стадии проектирования. Писать же запросы на работу с данными — круто и правильно.
Либо просьба развернуть вопрос подробнее — о чём речь вообще? )) Вот, например, «в профессиональной работе» — это в работе над чем, чем и зачем? А то пока всё слишком абстрактно.
-
-
23.01.2012 в 09:17С тех пор как закончила универ, ни разу не приходилось создавать таблицы конструктором или чем-то подобным. Всегда create table и т.д. С другой стороны софт с которым я больше всего работаю такой возможности и не дает (AS/400 DB2 IBM). В Оракле (Toad) вот даже не знаю есть ли конструктор, так как по привычке всегда создаю там все запросами.
В запросах на выборку вообще никогда конструкторами не пользовалась.
-
-
31.01.2012 в 23:12Ну, в работе администратора баз данных/ вообще их проектировщика. Можно вообще в целом, просто я за 9 лет обучения (а были у меня пару семестров максимум БД) знаю только access.
Т. е. мне интересно - при работе на фирме/предприятии, проектирующем БД (или работе в качестве фрилансера-проектировщика) для других организаций насколько надо знать сам язык sql? Или достаточно создать БД средствами самой программы, используя код разве что для работы с агрегирующими функциями, например (пока единственный плюс, что я заметил, пока делал работу по учёбе, поскольку при попытке вспомнить старое и задать запрос на агрегирующую функцию через построитель выражений не сработало)?
-
-
01.02.2012 в 00:51-
-
01.02.2012 в 21:20Знать надо, а вот использовать насколько надо?
VBA я вроде знаю для чего - элементы управления и всё остальное...
-
-
02.02.2012 в 01:55репликаторы, например.
То что вы описываете - это скорее интернет магазин, где в базу входят только таблицы товаров и заказов, и все функции сводятся только во вводе информации с формы и просмотре информации по заказам. Ну еще распечатать накладные какие-нибудь.
А если информация приходит из разных источников? Например, часть информации вводится руками, часть присылается в .xls, часть в .dbf файлах, часть приходит из почты. Нужно всю эту информацию как-то обработать, чтобы не руками вбивать и заносить по одной строчке, а автоматически грузить. А если еще допустим в .dbf вам приходит табличка часть полей которых заливается в БД 1 к 1, а часть высчитывается на основании уже имеющихся данных в таблицах БД и присланных. А тут еще и пришла необходимость хранить историю изменений, т.е. создавать таблицу в которой будут храниться все предыдущие состояния записи, чтобы можно было последовательно отследить, что и когда менялось. Нужно не только обновлять запись в таблице, но одновременно создавать запись в архивной таблице.
Теперь формы отчетов. Хорошо, если надо просто взять и распечатать накладную, а если нужно построить отчетность для налоговой? Нужно из 20-30 табличек стянуть данные, вывести их на экран, проверить, дать пользователю возможность, что-то подкорректировать, если где-то ошибки при загрузке случились. И хорошо бы, чтобы это был отдельный интерфейс, который подключается к базе через ODBC соединения например. Нужно разработать этот интерфейс, прописать ему все эти запросы и присвоения. Да так, чтобы отчет строился не трое суток, а максимум пару часов (от размера компании зависит)
Вот примерно - разработка.
Теперь сопровождение.
Строит у вас бухгалтер финансовую отчетность для той же налоговой, и видит, что по данным 1С одно, а в софтине стоящей отчет что-то не совсем так. Звонит она в поддержку и говорит, вот ошибки - исправьте. И вот вы лазаете по всем отчетам и репликаторам написанным совершенно не знакомыми вам людьми, со своими тараканами в голове. Нужно знать по каким принципам вообще все это работает, понять откуда вот это пришло и почему вот тут затерлось вон то поле. Потом понять, как это исправить, так как если исправить руками - то завтра репликатор автоматически исправит назад. Найти обходной путь, так называемое временное решение, поставить заплатку, при этом не сломать все остальное.
Еще у сопровождения постоянная проблема - рост БД, она реально будет только увеличиваться и с каждым годом, даже с учетом хранилищ данных и создания внешних архивов на лентах. Т.е. постоянно нужно следить, чтобы не произошло переполнение, потому что закончится место - все, вся система встанет. Встала система - огромные убытки и штрафы за просрочки. Некоторые системы при этом (МС кстати, этим грешит) могут устроить радость с переполнением не только самой БД, но таблиц. Расчитанна таблица, скажем на 10млрд записаей, и вот вы уже подошли к этой отметке, у вас авария.
А так же всякие уборщицы со швабрами, криворукие пользователи, которые вместо русских букв ввели английский ("Какая разница, они же одинаково выглядят?").
Вот это примерно 50% того, чем занимается поддержка, про остальную часть не буду писать, она сугубо профильная уже и от бизнеса зависит.
VBA я вроде знаю для чего - элементы управления и всё остальное...
Для создания и ведения БД в MS Access не достаточно знать для чего, нужно знать язык, чтобы точно описать действия тех же кнопок на формах.
-
-
02.02.2012 в 14:19Я и забыл, что кроме 3 частей языка SQL (DML, DDL и Select), являющихся, по сути, аналогом конструкторов, есть ещё DQL и пр.