Дуплекс

[Дмитрий Виницкий]

2000 помнится был мне предложен особо дешёвый телефонный план без определения входящего номера

Это был CDMA, по сути развитие колхозно-танковых сетей аля «Алтай».

[Дмитрий Виницкий]

Руководителю отдела / команды платили 1000+ (типично всё же 1500-2500), но никак не 3-4К.

Это была команда аврально исправлявшая косяки Corel. У них у всех в штатах стояли столы рабочие с табличками, а у меня с тех пор пожизненный корпоративный пароль на любую продукцию Corel 

[telekast]

Кредитки требовали прокатки

Ой, было и такое. Нда, так мы пейджеры вспомним. И этот, Турбо Паскаль.

Седьмой Турбопоскакал, да и этот, как его, учебник автора на Ф...
А году в 93-94 самым самым городом в мире по картам был Нерюнгри. Нерюнгрибанк договорился и внедрил систему "Золотая корона" практически на всех предприятиях. "Мировое сообщество ахнуло!"(тм)
ЗЫ. Фаронов! Во!

[Inti]

Для какого устройства приложение в 1991 году?

Для кладовщика и бухгалтера, е-моё!

скорее всего да.
Какой-то бэк-офис на писи. Фокс про или клиппер.
 Компьютерная жисть тогда была проста и незамысловата

Оно самое. Одно на клиппере а другое на фокс про. Но польза всё равно была. Про склад долго рассказывать. Про пиццерии. Клиент звонит и заказывает. Первый раз приходится спрашивать телефон, адрес, номер кредитки, и что он желает заказать. Второй и прочие разы спрашивают только номер телефона - а всё остальное уже известно из предыдущего заказа, в том числе и что именно человек заказывал, многие заказывают одно и то же, иногда с вариациями и комментариями. Заказ распечатывался и шёл на кухню, потом курьеру. Расчёты с курьерами тоже учитывались и в конце дня был отчёт кто сколько получает. Ничего особо сложного - но приложение ускоряло работу и уменьшало ошибки.

Для бд нужен уникальный ключ. Телефон в данном случае таковым не является, те с телефона может позвонить другой человек, гость, например. А вот номер кредитки является. При этом владелец кредитки может звонить с любого номера, хоть из таксофона.
Айтишнег. Зубр БД. Блин.

Кого там волновал какой-то уникальный ключ. Или определитель номера если он не был связан с компьютером. Человек звонил, оператор спрашивал какой номер телефона, на экране выскакивал адрес и прошлые заказы плюс кнопка "начать заказ с нуля". Оператор просто подтверждал адрес и имя, это ведь скорее чем набивать всё заново, но если скажем адрес менялся то его можно было обновить. И телефон можно было обновить по имени клиента. Как они там расплачивались я честно не знаю, скорее всего отдавали деньги курьеру. Я ни разу сотрудников этой сети пиццерий не видел, всё шло через одного знакомого немца, бизнесмена и владельца компьютерного магазина в котором я и сидел поначалу, а потом он мне подарил переносной комп величиной со швейную машинку в футляре и я также работал дома. Писал макрос для СУБД, ггг 

[telekast]

Для какого устройства приложение в 1991 году?

Для кладовщика и бухгалтера, е-моё!

скорее всего да.
Какой-то бэк-офис на писи. Фокс про или клиппер.
 Компьютерная жисть тогда была проста и незамысловата

Оно самое. Одно на клиппере а другое на фокс про. Но польза всё равно была. Про склад долго рассказывать. Про пиццерии. Клиент звонит и заказывает. Первый раз приходится спрашивать телефон, адрес, номер кредитки, и что он желает заказать. Второй и прочие разы спрашивают только номер телефона - а всё остальное уже известно из предыдущего заказа, в том числе и что именно человек заказывал, многие заказывают одно и то же, иногда с вариациями и комментариями. Заказ распечатывался и шёл на кухню, потом курьеру. Расчёты с курьерами тоже учитывались и в конце дня был отчёт кто сколько получает. Ничего особо сложного - но приложение ускоряло работу и уменьшало ошибки.

Для бд нужен уникальный ключ. Телефон в данном случае таковым не является, те с телефона может позвонить другой человек, гость, например. А вот номер кредитки является. При этом владелец кредитки может звонить с любого номера, хоть из таксофона.
Айтишнег. Зубр БД. Блин.

Кого там волновал какой-то уникальный ключ. Или определитель номера если он не был связан с компьютером. Человек звонил, оператор спрашивал какой номер телефона, на экране выскакивал адрес и прошлые заказы плюс кнопка "начать заказ с нуля". Оператор просто подтверждал адрес и имя, это ведь скорее чем набивать всё заново, но если скажем адрес менялся то его можно было обновить. И телефон можно было обновить по имени клиента. Как они там расплачивались я честно не знаю, скорее всего отдавали деньги курьеру. Я ни разу сотрудников этой сети пиццерий не видел, всё шло через одного знакомого немца, бизнесмена и владельца компьютерного магазина в котором я и сидел поначалу, а потом он мне подарил переносной комп величиной со швейную машинку в футляре и я также работал дома. Писал макрос для СУБД, ггг 

Кагншна, канешна. Пааадумаешь. Уникальный ключ это требование самой базы данных. По нему однозначно идентифицируется запись в таблице. Без него ничего работать не будет. Или это будет тупой текстовый поиск в текстовом документе. Может действительно там у тебя был Эксель и фильтр на столбец с номером телефона?
А ты реализовал задачу халтурно, по ламерски. Завести ключ в таблице "Клиенты" на кредитку трудно? Звонок. Назовите номер кредитки. Вколачиваем номер в форму, если такая кредитка есть, открываем историю заказов, игнорируя одинаковые в поле "Вид пиццы" в шапке ФИО, адрес, телефон. Гутентаг, херр Интя, вам кэгэбычно?! На Ундер Ден Линден 148, в подвал стучать три раза дай дай закурить? Ожидайте.
Если нет номера, то выскакивает форма ввода нового клиента. Все. Четыре таблицы. Дел на полдня с перекурами. И эта. Воткнуть дешманский войсмодем какой нить юр-спортсер на 14400 умеющий определять номер и отдать его в бд не судьба?
Айтишнег.

[vlad7308]

Фокс про или клиппер

Боюсь, кладовщик не разобрался бы

Да нет, почему..
Тогда все это писали. И оно даже вполне себе работало, вай нот. И спрос имело.
286, епсон lx и вот это вот все. Фоксы, клипперы и прочие xBase. Парадох еще, вот

[vlad7308]

Кредитки требовали прокатки

Ой, было и такое. Нда, так мы пейджеры вспомним. И этот, Турбо Паскаль.

так и речь про 91г

[Старый]

Кредитки требовали прокатки

Ой, было и такое. Нда, так мы пейджеры вспомним. И этот, Турбо Паскаль.

А может вообще кредитная карта работать без интернета? 

[vlad7308]

Уникальный ключ это требование самой базы данных. По нему однозначно идентифицируется запись в таблице

Неть. В xBase не требуется. (Да и в настоящих СУБД обычно нет).
Неявно он конечно всегда есть (номер записи в таблице). Более того, в xBase НЯП просто не было constraint primary key. Были только обычные индексы.

[vlad7308]

Кредитки требовали прокатки

Ой, было и такое. Нда, так мы пейджеры вспомним. И этот, Турбо Паскаль.

А может вообще кредитная карта работать без интернета?

Может. Работали же они как-то много десятилетий до всяких интернетов. Я даже застал, хехе. Причем именно кредитная может. Дебетовая - нет, они появились как раз вместе с онлайном.

[Старый]

По нему однозначно идентифицируется запись в таблице. Без него ничего работать не будет.

В Экселе будет! 

Или это будет тупой текстовый поиск в текстовом документе.

Не обижай чистопородный Эксель-6! 

[telekast]

Уникальный ключ это требование самой базы данных. По нему однозначно идентифицируется запись в таблице

Неть. В xBase не требуется. (Да и в настоящих СУБД обычно нет).
Неявно он конечно всегда есть (номер записи в таблице). Более того, в xBase НЯП просто не было constraint primary key. Были только обычные индексы.

"Как создать уникальный индекс в xBase?
В большинстве xBase систем для создания уникального индекса используется команда CREATE INDEX, с указанием имени индекса, имени поля (на которое будет ссылаться индекс) и флага UNIQUE или UNIQUE ON. 
Пример: CREATE INDEX имя_индекса ON поле_для_индекса UNIQUE. 
После создания уникального индекса при попытке вставки дублирующей записи в поле, на которое он ссылается, возникнет ошибка."(С)#изЫнета

[Inti]

Для какого устройства приложение в 1991 году?

Для кладовщика и бухгалтера, е-моё!

скорее всего да.
Какой-то бэк-офис на писи. Фокс про или клиппер.
 Компьютерная жисть тогда была проста и незамысловата

Оно самое. Одно на клиппере а другое на фокс про. Но польза всё равно была. Про склад долго рассказывать. Про пиццерии. Клиент звонит и заказывает. Первый раз приходится спрашивать телефон, адрес, номер кредитки, и что он желает заказать. Второй и прочие разы спрашивают только номер телефона - а всё остальное уже известно из предыдущего заказа, в том числе и что именно человек заказывал, многие заказывают одно и то же, иногда с вариациями и комментариями. Заказ распечатывался и шёл на кухню, потом курьеру. Расчёты с курьерами тоже учитывались и в конце дня был отчёт кто сколько получает. Ничего особо сложного - но приложение ускоряло работу и уменьшало ошибки.

Для бд нужен уникальный ключ. Телефон в данном случае таковым не является, те с телефона может позвонить другой человек, гость, например. А вот номер кредитки является. При этом владелец кредитки может звонить с любого номера, хоть из таксофона.
Айтишнег. Зубр БД. Блин.

Кого там волновал какой-то уникальный ключ. Или определитель номера если он не был связан с компьютером. Человек звонил, оператор спрашивал какой номер телефона, на экране выскакивал адрес и прошлые заказы плюс кнопка "начать заказ с нуля". Оператор просто подтверждал адрес и имя, это ведь скорее чем набивать всё заново, но если скажем адрес менялся то его можно было обновить. И телефон можно было обновить по имени клиента. Как они там расплачивались я честно не знаю, скорее всего отдавали деньги курьеру. Я ни разу сотрудников этой сети пиццерий не видел, всё шло через одного знакомого немца, бизнесмена и владельца компьютерного магазина в котором я и сидел поначалу, а потом он мне подарил переносной комп величиной со швейную машинку в футляре и я также работал дома. Писал макрос для СУБД, ггг 

Кагншна, канешна. Пааадумаешь. Уникальный ключ это требование самой базы данных. По нему однозначно идентифицируется запись в таблице. Без него ничего работать не будет. Или это будет тупой текстовый поиск в текстовом документе. Может действительно там у тебя был Эксель и фильтр на столбец с номером телефона?
А ты реализовал задачу халтурно, по ламерски. Завести ключ в таблице "Клиенты" на кредитку трудно? Звонок. Назовите номер кредитки. Вколачиваем номер в форму, если такая кредитка есть, открываем историю заказов, игнорируя одинаковые в поле "Вид пиццы" в шапке ФИО, адрес, телефон. Гутентаг, херр Интя, вам кэгэбычно?! На Ундер Ден Линден 148, в подвал стучать три раза дай дай закурить? Ожидайте.
Если нет номера, то выскакивает форма ввода нового клиента. Все. Четыре таблицы. Дел на полдня с перекурами. И эта. Воткнуть дешманский войсмодем какой нить юр-спортсер на 14400 умеющий определять номер и отдать его в бд не судьба?
Айтишнег.

Вот она разница между профессиональным программистом и любителем-недоучкой.

На хрена делать кредитную карту ключом? У человека их может быть несколько, и он может сегодня использовать одну а завтра другую, а может вообще кредитки не иметь.

В качестве ключа лучше использовать уникальный номер клиента который создаётся автоматически для каждого нового заказчика пиццы, и тогда можно спокойно менять и номер кредитки, и адрес и телефон, и даже имя клиента (что тоже полезно если первый раз вбили с ошибкой). Найти клиента можно конечно и по имени, просто телефон используется чаще всего. Причём его даже полностью вбивать было не надо потому что на второй-третьей цифре он уже как правило находился в базе данных, я любил делать подобные поиски по частичному совпадению, причём без нажатия ENTER, оператор просто печатал и тут же выскакивал сужающийся список совпадений.

Ничего хитрого для меня в этой задаче не было, но и за полдня с перекурами такое приложение тоже не напишешь чтобы всё было профессионально и удобно для заказчика. Тем более что сам заказчик добавлял новые требования, например для учёта оплаты курьеров, их машин и прочих мелочей, например личных данных курьера и т.п.

За полдня и 100 долларов делают Телекасты, а я беру дороже и делаю качественный полезный продукт. 

Кстати, когда я показал как всё выглядит и работает одному знакомому немцу который работал в BP(British Petroleum), то он скопировал всё это и показал своему начальству. Они поначалу возбудились, типа именно такой парень нам сейчас нужен, но узнав что я кандидат в беженцы без права работы, посоветовались со своим юристом и сказали что к сожалению ничего не получится. А так-то было бы отличное место работы, и все там английский знали, моё плохое знание немецкого было бы неважным.

[Старый]

В качестве ключа лучше использовать уникальный номер клиента который создаётся автоматически для каждого нового заказчика пиццы

И каждый клиент должен помнить свой номер и при заказе называть его? 

[vlad7308]

Уникальный ключ это требование самой базы данных. По нему однозначно идентифицируется запись в таблице

Неть. В xBase не требуется. (Да и в настоящих СУБД обычно нет).
Неявно он конечно всегда есть (номер записи в таблице). Более того, в xBase НЯП просто не было constraint primary key. Были только обычные индексы.

"Как создать уникальный индекс в xBase?
В большинстве xBase систем для создания уникального индекса используется команда CREATE INDEX, с указанием имени индекса, имени поля (на которое будет ссылаться индекс) и флага UNIQUE или UNIQUE ON.
Пример: CREATE INDEX имя_индекса ON поле_для_индекса UNIQUE.
После создания уникального индекса при попытке вставки дублирующей записи в поле, на которое он ссылается, возникнет ошибка."(С)#изЫнета

Кажется возможность создания уникального индекса появилось начиная с dBase 5,  то есть уже в середине 90х. Но неважно.
Первичный ключ все равно не требуется.

ЗЫ sql с xBase гггг

[Дмитрий Виницкий]

который работал в BP

И там не читали мануалы

[Дмитрий Виницкий]

Работали же они как-то много десятилетий до всяких интернетов

Это была просто система чеков, где зачисление происходило после ручной обработки в банке поступивших слипов с прославленным номером карты. Так что я очень сомневаюсь в торговле пиццей с доставкой с оплатой картой в 1991 году. Это надо каждому курьеру с собой эмбоссер возить с книжкой.

[telekast]

Для какого устройства приложение в 1991 году?

Для кладовщика и бухгалтера, е-моё!

скорее всего да.
Какой-то бэк-офис на писи. Фокс про или клиппер.
 Компьютерная жисть тогда была проста и незамысловата

Оно самое. Одно на клиппере а другое на фокс про. Но польза всё равно была. Про склад долго рассказывать. Про пиццерии. Клиент звонит и заказывает. Первый раз приходится спрашивать телефон, адрес, номер кредитки, и что он желает заказать. Второй и прочие разы спрашивают только номер телефона - а всё остальное уже известно из предыдущего заказа, в том числе и что именно человек заказывал, многие заказывают одно и то же, иногда с вариациями и комментариями. Заказ распечатывался и шёл на кухню, потом курьеру. Расчёты с курьерами тоже учитывались и в конце дня был отчёт кто сколько получает. Ничего особо сложного - но приложение ускоряло работу и уменьшало ошибки.

Для бд нужен уникальный ключ. Телефон в данном случае таковым не является, те с телефона может позвонить другой человек, гость, например. А вот номер кредитки является. При этом владелец кредитки может звонить с любого номера, хоть из таксофона.
Айтишнег. Зубр БД. Блин.

Кого там волновал какой-то уникальный ключ. Или определитель номера если он не был связан с компьютером. Человек звонил, оператор спрашивал какой номер телефона, на экране выскакивал адрес и прошлые заказы плюс кнопка "начать заказ с нуля". Оператор просто подтверждал адрес и имя, это ведь скорее чем набивать всё заново, но если скажем адрес менялся то его можно было обновить. И телефон можно было обновить по имени клиента. Как они там расплачивались я честно не знаю, скорее всего отдавали деньги курьеру. Я ни разу сотрудников этой сети пиццерий не видел, всё шло через одного знакомого немца, бизнесмена и владельца компьютерного магазина в котором я и сидел поначалу, а потом он мне подарил переносной комп величиной со швейную машинку в футляре и я также работал дома. Писал макрос для СУБД, ггг 

Кагншна, канешна. Пааадумаешь. Уникальный ключ это требование самой базы данных. По нему однозначно идентифицируется запись в таблице. Без него ничего работать не будет. Или это будет тупой текстовый поиск в текстовом документе. Может действительно там у тебя был Эксель и фильтр на столбец с номером телефона?
А ты реализовал задачу халтурно, по ламерски. Завести ключ в таблице "Клиенты" на кредитку трудно? Звонок. Назовите номер кредитки. Вколачиваем номер в форму, если такая кредитка есть, открываем историю заказов, игнорируя одинаковые в поле "Вид пиццы" в шапке ФИО, адрес, телефон. Гутентаг, херр Интя, вам кэгэбычно?! На Ундер Ден Линден 148, в подвал стучать три раза дай дай закурить? Ожидайте.
Если нет номера, то выскакивает форма ввода нового клиента. Все. Четыре таблицы. Дел на полдня с перекурами. И эта. Воткнуть дешманский войсмодем какой нить юр-спортсер на 14400 умеющий определять номер и отдать его в бд не судьба?
Айтишнег.

Вот она разница между профессиональным программистом и любителем-недоучкой.

На хрена делать кредитную карту ключом? У человека их может быть несколько, и он может сегодня использовать одну а завтра другую, а может вообще кредитки не иметь.

В качестве ключа лучше использовать уникальный номер клиента который создаётся автоматически для каждого нового заказчика пиццы, и тогда можно спокойно менять и номер кредитки, и адрес и телефон, и даже имя клиента (что тоже полезно если первый раз вбили с ошибкой). Найти клиента можно конечно и по имени, просто телефон используется чаще всего. Причём его даже полностью вбивать было не надо потому что на второй-третьей цифре он уже как правило находился в базе данных, я любил делать подобные поиски по частичному совпадению, причём без нажатия ENTER, оператор просто печатал и тут же выскакивал сужающийся список совпадений.

Ничего хитрого для меня в этой задаче не было, но и за полдня с перекурами такое приложение тоже не напишешь чтобы всё было профессионально и удобно для заказчика. Тем более что сам заказчик добавлял новые требования, например для учёта оплаты курьеров, их машин и прочих мелочей, например личных данных курьера и т.п.

За полдня и 100 долларов делают Телекасты, а я беру дороже и делаю качественный полезный продукт.

Кстати, когда я показал как всё выглядит и работает одному знакомому немцу который работал в BP(British Petroleum), то он скопировал всё это и показал своему начальству. Они поначалу возбудились, типа именно такой парень нам сейчас нужен, но узнав что я кандидат в беженцы без права работы, посоветовались со своим юристом и сказали что к сожалению ничего не получится. А так-то было бы отличное место работы, и все там английский знали, моё плохое знание немецкого было бы неважным.

Ты не профессионал, а халтурщик.

"Несколько кредиток" у одного человека, заказчика пиццы в 90м году? Не смеши мои тапки. И как человек, не имеющий кредитки, будет заказывать И ОПЛАЧИВАТЬ пиццу по телефону? В телефонный счёт ему будешь стоимость ее включать?

Клиент должен помнить уникальный номер? Нафига. Кредитка у него всегда с собой, второй такой же нет, достал, продиктовал. Вот это валенка, типа тебя, и отличает от человека понимающего.
Исправить ошибку можно в любой момент, если есть соответствующие права. В любом поле допускающим внесение изменений(все, кроме ключа).
Великое, блин, дело написать запрос, где в поле фильтра использовать постановочные знаки "?" и "*" и повесить перевызов/обновление запроса на событие изменения данных в поле ввода.

Я писал. Это вообще типовая задача и во многих БД имеется в виде готового шаблона. Добавление хотелок заказчика, типа учёта заказов по курьерам и тд тоже ничего сложного, если он не начинает менять исходные установки.

Ты сделал говнопродукт в котором изначально оставил несколько дыр и возможность ошибки. Мною написанные(не за полдня, ессно) работали десятилетиями. Например система автоматизации бегущей строки для телекомпании. Тебе, халтурщик, до такого уровня год нечистотами плыть.

Сказки про жЫстоких немцев, погасивших трепетный огонек таланта мы уже слышали.

[telekast]

Уникальный ключ это требование самой базы данных. По нему однозначно идентифицируется запись в таблице

Неть. В xBase не требуется. (Да и в настоящих СУБД обычно нет).
Неявно он конечно всегда есть (номер записи в таблице). Более того, в xBase НЯП просто не было constraint primary key. Были только обычные индексы.

"Как создать уникальный индекс в xBase?
В большинстве xBase систем для создания уникального индекса используется команда CREATE INDEX, с указанием имени индекса, имени поля (на которое будет ссылаться индекс) и флага UNIQUE или UNIQUE ON.
Пример: CREATE INDEX имя_индекса ON поле_для_индекса UNIQUE.
После создания уникального индекса при попытке вставки дублирующей записи в поле, на которое он ссылается, возникнет ошибка."(С)#изЫнета

Кажется возможность создания уникального индекса появилось начиная с dBase 5,  то есть уже в середине 90х. Но неважно.
Первичный ключ все равно не требуется.

ЗЫ sql с xBase гггг

Что нашлось, то нашлось. Я в хэВасе не работал*смайлик пожимающий плечами с разведёнными руками*

[vlad7308]

Что нашлось, то нашлось. Я в хэВасе не работал*смайлик пожимающий плечами с разведёнными руками*

Зато я работал. 🤷